💾 Archived View for rawtext.club › ~sloum › geminilist › 002076.gmi captured on 2020-09-24 at 01:27:05. Gemini links have been rewritten to link to archived content

View Raw

More Information

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

<-- back to the mailing list

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 rightdirection, you just took it too far. :)

It's basically just a trade-off. If certificates never, ever expirethen TOFU is very simple and clients will never have to show scarymessages under ordinary circumstances when everything is fine, but therisk of the private key being stolen or broken (keys which are longenough to be safe today will not be decades later) is very high, and ifit happens, the consequences last forever. If certificates expire everyweek, it's very hard to steal or crack a key before the correspondingcert expires, but TOFU is unworkable without some extra complication ontop. The best approach is somewhere in the middle. The question is:where?

On the web, certificate lifetimes are getting shorter and shorter - butCAs have a strong financial incentive to be risk averse here, becausebad publicity around a single, long-lasting erroneously issued cert willdamage their reputation and hence business, possibly quite hard. ButGemini server admins using self-signed certs don't have that risk atall. Also, on the web, TLS is often protecting credit card details, oraccess to email, or other things people have a strong incentive toactively try to steal. A personal Gemini host serving a gemlog is notlikely to be the target of serious efforts at compromise, so yet lessreason to be super cautious about key rotation. For low-riskapplications, a five year certificate might be perfectly reasonable.

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

Cheers,Solderpunk