[OT] RFC8890

[Martin Keegan]

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.

Mk

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