SSHFP and the TOFU Issue

When a user connects to an unknown ssh server for the first time they are presented with the host key fingerprint for that server and recommended to confirm that this host key is correct. The expectation is that a user will look out-of-bounds for that, by making a phone call, sending an email, looking something up online, etc. It's often ignored, but those who do it often end up looking on a website for the fingerprint in a footer or about page.

A few months back I speculated that it would be better to store this fingerprint in a DNS txt record than on a website that's most likely hosted on the same server you're logging into. If that server were compromised or hijacked it would be trivial for the bad actor to update the fingerprint on the website since they now control that too. It would be much harder, though, to compromise the DNS entries at the same time as the server.

Fast-forward to today when I checked with a friend more experienced at DNS things than I am to see if I was reinventing the wheel. Sure enough, I was.

Allow me to introduce you to the SSHFP Record:

SSHFP Record on Wikipedia

This is far superior to my basic txt entry idea because it provides a reliable mechanism to automate verification of that fingerprint by providing all the relevant details. It also notes on the wiki page that with DNSSEC in place you can be assured of a chain-of-trust.

Now we're faced with an extremely similar challenge in Gemini with TLS and TOFU (trust on first use). If we look to the pattern established already by SSHFP we could easily copy that to create a GEMINIFP record that achieves the same result. Chain-of-trust without a central authority!

Have at it, nerds. Set the mailing list aflame with discussion.

Originally Published 2021-03-31 at:

gemini://tilde.team/~tomasino/journal/20210331-sshfp-and-the-tofu-issue.gmi

If you have questions or thoughts to add please send me a link to your response.

Contact Information