Björn Wärmedal bjorn.warmedal at gmail.com
Mon Mar 8 12:38:24 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Mon, 8 Mar 2021 at 13:28, Stephane Bortzmeyer <stephane at sources.org> wrote:
Gemini already has one way to announce this intention. To quote the
spec, "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". So, to announce your intention to change the certificate,
just say so in the expiration date (notAfter field).
In other words broadcast to potential attackers when the best time todo a MitMA is :)
If clients silently accept new certificates this gets even worse,because it opens a window where the attack can happen without anyoneknowing.
A certificate that's valid for 90 days, ending 9 days from now, cansilently be replace by another certificate with the samenot-valid-before and not-valid-after, allowing the attacker 9 days ofunnoticed operation.
I think we've pretty much laid out all the pros and cons of TOFU as avalidation scheme. I personally believe there is very little benefitto trying to make it more secure, compared to the added complexity.
We need to clarify the spec around what TOFU means for clients andservers, and that includes removing advice like "checknot-valid-before, hostname, and not-valid-after" and that certificatesshould be rotated.
Or we need to decide to not use TOFU. I'm not going to reiterate thealternatives I see, but suffice to say that I think this is an issueof "decide which set of pros and cons to accept".
Cheers,ew0k