Updated recommendations regarding TOFU & TLS

Philip Linde linde.philip at gmail.com
Fri Mar 5 12:13:47 GMT 2021

On Thu, 04 Mar 2021 11:43:49 -0500
"Drew DeVault" <sir at cmpwn.com> wrote:

> - Use long-lived certificates with the expiration set to the far future

That makes perfect sense for TOFU. If for whatever reason you need to
renew a certificate (e.g. to use stronger encryption) you can just swap
it out. The clients will (hopefully) learn of the change and can choose
whether to trust the new certificate.

> - Client software should disregard notBefore/notAfter dates, and the
>   common name as well. Requiring strong algorithms and other technical
>   constraints is fine.

What is the motivation for ignoring CN?

> Any server software which wants to migrate to long-lived certificates
> should let their current certificates expire and then automatically
> issue a long-lived certificate to replace it when the time comes, rather
> than switching immediately and causing your clients to flag your cert as
> untrusted.

Without a chain of trust, and ignoring notBefore/notAfter, there's no
point in waiting.

The client (according to the procedure you describe in your article)
will find the old cert in known_hosts in step 2., see that the served
certificate differs and consider the new certificate UNTRUSTED. That is
true regardless of whether you immediately replace the certificate or
wait until the old one has expired, unless the client *doen't* ignore
notBefore/notAfter and uses those dates to vacuum known_hosts to remove
expired certificates automatically (which is impossible given the store
format you currently recommend).

The procedure you describe does not provide for any other way to roll
out new certificates than for the new one to be UNTRUSTED, nor do I
think clients are able to provide this in general outside the use of
certificate authorities or validity date based vacuuming of known_hosts.

That's really how it has to be for TOFU: whenever a new certificate is
used, a new trust has to be established. *Any* certificate that
you haven't used is untrusted.

IMO, UNKNOWN is really the same thing as UNTRUSTED. There is no
UNKNOWN state; either I've asserted my trust in the certificate or I
haven't. UNKNOWN and UNTRUSTED are just different cases of untrusted
certificates, with latter giving you an additional piece of
information: that you have already trusted a different certificate for
the given host. I think it's better for clients if they are treated as

In my client, the user gets a choice whenever they encounter a new
certificate. If the trust store happens to contain a different
certificate for the host, that information will be displayed to the
user as well, so that they can use it as a basis for the decision
whether to trust the new certificate. Manually editing known_hosts is
just that, "with extra steps".

> To re-state one of my previous recommendations, which I still figure is
> a good idea: server software should handle certificate maintenance for
> the user. Making the sysadmin generate certificates is cumbersome and
> error prone, and because Gemini encourages TOFU and self-signed
> certificates, we can remove that burden from server operators entirely
> by generating certificates on-demand for the hosts we intend to service.


> Aside: it might be a good idea to have a non-authoratitive TLS
> best-practices document on gemini.circumlunar.space somewhere. I'd be
> happy to draft up such a document if this is desirable.

Agreed. I think your article is a good starting point, but consider my
criticism above.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210305/17dbaf8c/attachment.sig>

More information about the Gemini mailing list