Removing expiry dates for TOFU

Solderpunk solderpunk at posteo.net
Sun Jul 5 22:20:11 BST 2020


On Sun Jul 5, 2020 at 8:48 PM CEST,  wrote:
> Looks like it was a bad idea after all haha. I wasn't sure about it,
> so thanks for showing some issues with it.
>
> Maybe this is a better solution, everyone using longer term certs? It
> still might not be enough though.
>
> My thinking behind my original post was that the fewer valid reasons for
> changing certs the better. If changing certs is very rare, then clients
> can be more informative to the user, and say with more surety that there
> is a MITM attack going on. How can we lessen the behaviour of just
> clicking through any TOFU pop-up?

Well, I think your overall thinking was very much in the right
direction, you just took it too far. :)

It's basically just a trade-off.  If certificates never, ever expire
then TOFU is very simple and clients will never have to show scary
messages under ordinary circumstances when everything is fine, but the
risk of the private key being stolen or broken (keys which are long
enough to be safe today will not be decades later) is very high, and if
it happens, the consequences last forever.  If certificates expire every
week, it's very hard to steal or crack a key before the corresponding
cert expires, but TOFU is unworkable without some extra complication on
top.  The best approach is somewhere in the middle.  The question is:
where?

On the web, certificate lifetimes are getting shorter and shorter - but
CAs have a strong financial incentive to be risk averse here, because
bad publicity around a single, long-lasting erroneously issued cert will
damage their reputation and hence business, possibly quite hard.  But
Gemini server admins using self-signed certs don't have that risk at
all.  Also, on the web, TLS is often protecting credit card details, or
access to email, or other things people have a strong incentive to
actively try to steal.  A personal Gemini host serving a gemlog is not
likely to be the target of serious efforts at compromise, so yet less
reason to be super cautious about key rotation.  For low-risk
applications, a five year certificate might be perfectly reasonable.

One could argue that longer lived certs actually help TOFU work, within
reason.  The longer a cert is in use, the more opportunity you have to
observe that cert being served to you from multiple different networks
(at home, at work, at the library, at the airport), which helps build
up your trust in it: getting MITMed once on a single network might be a
plausible risk.  Being consistently MITMed every time you visit a host,
from multiple locations, for years and years, is almost impossible, so
the longer you see the same cert, the more confident you can become that
when you blindly accepted the cert the very first time you weren't being
attacked.

Cheers,
Solderpunk


More information about the Gemini mailing list