TOFU recommendations for Gemini clients

I wrote up my client's TOFU procedure into an article here:

https://drewdevault.com/2020/09/21/Gemini-TOFU.html

I hope that this is useful to other client authors.

On Wed, Sep 23, 2020 at 02:49:05PM -0400, Drew DeVault wrote:
> I wrote up my client's TOFU procedure into an article here:
> 
> https://drewdevault.com/2020/09/21/Gemini-TOFU.html
> 
> I hope that this is useful to other client authors.

Thank you Drew, this is very helpful. I keep trying to find time to work 
on a Gemini client and when I do, having well thought out TOFU notes will be great.

Brad

Hello Drew,

You might be interested in a gemlog post I wrote a while back, with basically
the same topic, it's my TOFU recommendations for Gemini.

gemini://makeworld.gq/gemlog/2020-07-03-tofu-rec.gmi

My recommendations are pretty similar to yours. A few differences:

- I don't specify a file/storage format
- The cert fingerprint is generated from just the SPKI section of the cert,
   not the entire thing. See the post for rationale.
- The port is also stored (host vs hostname) so that different ports can
   use different certs
- I don't make any distinction between temporary and always trust
- I mention SHA-256, but that's just an implementation detail

I also noticed that your flow doesn't seem to update the host data if the
cert has expired, it just allows the request to continue. I assume that's
an error? Or maybe I'm misreading.

Would be happy to hear about what you think of my recommendations! I hope
they're useful, I've been trying to spread them on Gemini since I wrote them.

Cheers,
makeworld

On Thu Oct 1, 2020 at 5:55 PM EDT,  wrote:
> - I don't specify a file/storage format

Yeah, it's not necessary for us to standardize, but for what it's worth
at least one other client has implemented my known_hosts format and I
moved it to a more general location (~/.local/share/gemini), so we have
a chance to establish a software agnostic trust store if we so desire.

> - The cert fingerprint is generated from just the SPKI section of the
> cert, not the entire thing. See the post for rationale.

Aye, your rationale is good. Like I mentioned, the reason I hash the
whole thing is to match the output of openssl x509 -sha512 -fingerprint,
so that it's easier to independently verify the fingerprint.

The ability for the server operator to replace the cert with a fresh one
with the same PK and have the TOFU entry remain trusted is interesting,
but seems fraught with some risk. In any case, I'm of the opinion that
operators should never directly handle certificate maintenance in a TOFU
system.

> - The port is also stored (host vs hostname) so that different ports can
> use different certs

Good call, I'll think about this.

> - I mention SHA-256, but that's just an implementation detail

I just went with SHA-256 because I don't expect these files to be
hand-edited often and the hash, while longer and more cumbersome, is
more likely to be useful for longer.

> I also noticed that your flow doesn't seem to update the host data if
> the cert has expired, it just allows the request to continue. I assume
> that's an error? Or maybe I'm misreading.

The first step is to validate the certificate independently of the trust
store. If it has expired, it would fail this step. Other things checked
here include the valid hostnames, desired hashing algorithms, or
anything else you find it useful to validate. Technically we don't even
need to store the expiration.

So yeah, the known hosts data does not get updated when the cert
expires, but the expired cert would not be trusted anyway.

> Would be happy to hear about what you think of my recommendations! I
> hope they're useful, I've been trying to spread them on Gemini since I
> wrote them.

Thanks for sharing! I'll add a link to my article.