Enhancing TOFU

[Björn Wärmedal]

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 to
do a MitMA is :)

If clients silently accept new certificates this gets even worse,
because it opens a window where the attack can happen without anyone
knowing.

A certificate that's valid for 90 days, ending 9 days from now, can
silently be replace by another certificate with the same
not-valid-before and not-valid-after, allowing the attacker 9 days of
unnoticed operation.

I think we've pretty much laid out all the pros and cons of TOFU as a
validation scheme. I personally believe there is very little benefit
to trying to make it more secure, compared to the added complexity.

We need to clarify the spec around what TOFU means for clients and
servers, and that includes removing advice like "check
not-valid-before, hostname, and not-valid-after" and that certificates
should be rotated.

Or we need to decide to not use TOFU. I'm not going to reiterate the
alternatives I see, but suffice to say that I think this is an issue
of "decide which set of pros and cons to accept".

Cheers,
ew0k