💾 Archived View for rawtext.club › ~sloum › geminilist › 006010.gmi captured on 2023-09-28 at 16:57:20. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Thomas Frohwein tfrohwein at fastmail.com
Mon Mar 8 18:42:32 GMT 2021
- - - - - - - - - - - - - - - - - - -
I have written up how clients and servers can support out-of-band pubkeyverification to add a higher level of trust where needed. My opinion isthat for 99% of connections made by most clients, TOFU provides sufficientsecurity. For those situations where TOFU is judged by the user to beinsufficiently secure, clients can (sic) offer a variety of differentways to support easy out-of-band verification.
I call this approach "Trust, but Verify (where appropriate)."
In a nutshell, 3 security levels would be offered and displayed by aclient following this, the first 2 of which are already part of TOFU:
- red: untrusted, mostly if certificate mismatch is encountered- yellow: trusted, likely the large majority of all connections, here the host cert matches the known host of the same name- green: verified - cert matches known host, plus the client has matched the cert with an out-of-band digest of the cert, confirming the identity of the server. This would be useful for connections involving sensitive information.
The details should be left to the client, with some technically simpleexamples provided (entering/pasting pubkey hash, random art like'ssh-keygen -lv'). A variety of technically more complicated ways toconfirm the pubkey like TLSA, DANE, TXT records could fall into thisapproach, too, but I think it could be left up to the client and serverswhat ways to offer to support the verification.
The full write-up is hosted here:
gemini://thfr.info/gemini/modified-trust-verify.gmi
thfr