💾 Archived View for makeworld.space › gemlog › 2020-07-05-tofu-2.gmi captured on 2022-01-08 at 13:52:34. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Another idea for TOFU

Response

Solderpunk has responded to this on the mailing list, and outlined why he thinks it's a bad idea. An excerpt:

Using the same keypair for a very long time is generally considered a bad idea, as it increases both the risk of key compromise and the duration for which a stolen key can be exploited. There's also the issue of ownership of domain names changing over long timespans, and former legitimate domain owners being able to impersonate new legitimate domain owners with old certificates. Even CA certificates have expiry dates. I don't think we should be advising people to use certs which last forever.

He has suggested using 5 year certs instead.

The original post

In my previous post, I outlined a guide and recommendations for implementing TOFU for Gemini. It was written with the current state of Gemini in mind, where most sites' certs expire within the year, where expiration and cert changes happen somewhat often.

My previous post (TOFU Recommendations)

But last night mozz (of mozz.us) raised an idea to me in a Github comment. Why care about expiration dates at all for TOFU? With a TOFU system, all the trust is placed in the keypair of your cert, and so expiration dates have less value. Right now, certs expire all the time, and so certs change all the time. This has two effects:

Users will accept any cert change, because it happens often and they just want to view content
There are lots of opportunities for a MITM attack, because it can happen when a cert expires, and clients will just accept it because the old cert expired

mozz's Github comment - might be good to read this first

A better solution would be a system where clients don't care about expiry dates, and expect a site's cert to continue forever. And as a precaution, sysadmins could generate certs for a 100 years in the future or something, but it wouldn't actually matter for those clients that don't look at certs, it would just be for the ones that do.

Here are the changes from my original post that this system would require:

Don't store the expiry date at all
Clients should hash/store the Subject Public Key Info (SPKI) section of the cert instead of the whole thing, because the whole cert would contain the expiry date. This is less of an issue as servers start using 100-year-certs or something, but it'd still be good
*Always* notify the user when the cert changes, don't accept it silently like the original post suggested to do if the cert had expired.
Make the cert change message more aggressive and scary. With the system described above, cert changes would be rare, and more indicative of an attack.

For server sysadmins:

Generate a cert with a very far away expiry date, and back it up!
Change your current cert to this new one ASAP

Solderpunk has mentioned how he wants to create a command line tool for to generate certs for Gemini. I would suggest for him to make the expiry date default to 100 years in the future, to stay in line with this idea. I don't see any downsides to this.

Coda

I have submitted this post to the Gemini mailing list. Let's keep discussion there.