Thoughts on TOFU

It was thus said that the Great Felix Quei?ner once stated:
> Hey List!
> 
> While planning out the implementation of TOFU for Kristall, i noticed
> something weird:
> 
> Quoting the spec:
> ----------------------------------------------------------------------
> TOFU stands for "Trust On First Use" and is public-key security model
> similar to that used by OpenSSH.  The first time a Gemini client
> connects to a server, it accepts whatever certificate it is presented.
> That certificate's fingerprint and expiry date are saved in a persistent
> database (like the .known_hosts file for SSH), associated with the
> server's hostname.  On all subsequent connections to that hostname, the
> received certificate's fingerprint is computed and compared to the one
> in the database.  If the certificate is not the one previously received,
> but the previous certificate's expiry date has not passed, the user is
> shown a warning, analogous to the one web browser users are shown when
> receiving a certificate without a signature chain leading to a trusted CA.
> ----------------------------------------------------------------------
> 
> This means that trust in a server is lost as soon as a certificate is
> expired and a subsequent renewal of the certificate with the same
> private key is the same as visiting the host for the first time. But
> when i refresh my server certificate before it expires (which is
> recommended), we will have the situation that the client will not trust
> the server anymore (same situation as when an attacker is doing a MITM
> attack) which i think is not a good situation.
> 
> My proposal for both server certificates is the following:
> An endpoint stores the public key of the servers certificate as well as
> the host name. As long as this host continues to use the same identity
> (pub+privkey), it will be trusted. Certificates that aren't refreshed
> will error to the client, having another pubkey presented will error
> "harder" (as in: this is a possible MITM attack)
> 
> The same behaviour could be used for client certificates as well,
> allowing the renewal of client certificates with the same private key
> (which would solve the "how do i have persistent identities")
> 
> What do you guys think?

  I think that's reasonable, as the client certificate for gemini.conman.org
is set to expire in a few days (I run my own CA as an experiment).  

  -spc

---

Previous in thread (1 of 12): 🗣️ Felix Queißner (felix (a) masterq32.de)

Next in thread (3 of 12): 🗣️ solderpunk (solderpunk (a) SDF.ORG)

View entire thread.