💾 Archived View for rawtext.club › ~sloum › geminilist › 002511.gmi captured on 2020-10-31 at 14:35:42. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

[OT] RFC8890

Martin Keegan martin at no.ucant.org

Fri Aug 28 13:12:00 BST 2020

- - - - - - - - - - - - - - - - - - -

On Fri, 28 Aug 2020, Petite Abeille wrote:

Perhaps of interest, courtesy of Mark Nottingham:

The Internet is for End Users

https://www.mnot.net/blog/2020/08/28/for_the_users

https://tools.ietf.org/html/rfc8890

Thank you for this link. I note that the blog posts references an "encrypted client hello proposal", at https://tools.ietf.org/html/draft-ietf-tls-esni-07

I thought I had posted to this list my long-standing opinion that TLS/SSL effectively forces a choice between confidentiality and anonymity: if you want encrypted communications you need to reveal to an eavesdropper the identity of any endpoint that wants to be authenticated to another endpoint. This has been part of an unease I've had with SSL since it was introduced 25 years ago, though until recently it was mainly that the overhead of PKI was too high for small-time servers. The overhead is *still* too high because LetsEncrypt is still somewhat immature.

Peter Vernigorov wrote on this list recently that SSL is actually a bit worse than most people expected: https://lists.orbitalfox.eu/archives/gemini/2020/002282.html

I ran a packet sniffer on some Gemini client (gcat?) and discovered to my horror that he was right: the subject identity of the client certificate is sent in plain text over the wire: SSL does indeed force the deanonymisation of an endpoint wishing to be relied upon in return for encrypting the non-metadata content of the communication.

The IETF draft RFC referenced the piece that the OP posted would seem to address this issue, which is critical for Gemini, as Gemini places more reliance on client certificates than is usual (hitherto) in customary Internet applications.

-- Martin Keegan, +44 7779 296469, @mk270, https://mk.ucant.org/