Re: [TLS] WGLC for draft-ietf-tls-sni-encryption

[Eric Rescorla <[e-mail]>]

On Wed, Oct 17, 2018 at 10:03 AM Martin Rex <[e-mail]> wrote:

> Sean Turner <[e-mail]> wrote:
> >
> > This is the working group last call for the
> > "Issues and Requirements for SNI Encryption in TLS"
> > draft available at
> > http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/.
> > Please review the document and send your comments to the list
> > by 2359 UTC on 31 October 2018.
>
>
> I think the idea of encrypted SNI is inherently flawed in its concept.
>

It's pretty late to raise this point as we've had repeated consensus calls
to
work on this.
If anyone really thinks that there should be a scheme where a server's


> hostname is no longer transfered in a cleartext (including TLS extension
> SNI),
> then first of all a *NEW* distinct URI method should be defined for that
> purpose,  e.g. "httph://"  as a reliable indicator to the client processing
> this URI, that the hostname from this URI is not supposed to be sent
> over the wire in the clear *anywhere*
>


> As it is, there are a number of servers which desperately require
> the presence of TLS extension SNI, or will fail TLS handshakes either
> by choking and dropping connections (Microsoft IIS 8.5+) or by
> very unhelpful alerts (several others), and also HTTP/2.0 requires
> unconditional cleartext presence of TLS extension SNI.  Any kind of
> heuristics-based approach for clients to guess whether or not to
> send TLS extension SNI is flawed from the start.  If a network
> middlebox can make a client present a cleartext TLS extension SNI
> by refusing connections without cleartext TLS extension SNI,
> the entire effort becomes pretty useless.


Yes, clients must not fall back to cleartext SNI in this case.


  It is necessary
> that the client knows reliably that a hostname must not be sent
> in the clear, including when the connection fails for unknown reasons,
> and only a new URI method will reliably provide such a clear distinction.
>

I don't agree with this claim, given that we have a number of other proposed
mechanisms for the client to know when ESNI is allowed, including DNS.
It's true that middleboxes might block these requests, but
https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-6.2 has some
material on this. Comments welcome. In any case, I don't see why
a URI is better than DNS in this case..



> By sending TLS extension SNI in the clear to a server, the client
> tells that server:  I am going to perform an rfc2818 "HTTP over TLS"
> section 3.1 "Server Endpoint Identification" matching


I don't know where you get this from, given that RFC 6066 doesn't
even cite 2818.



In protocol version SSLv3->TLSv1.2, encryption keys are only established
> *AFTER* successful authentication of the server through its server
> certificate. So it was obviously impossible to encrypt the information
> whose only purpose it was to allow the server to decide *which* TLS Server
> certificate to use for authentication (hen-and-egg).
>

This isn't really correct: the mechanism for encrypting SNI itself would
actually work
fine in previous versions of TLS as well. It's just that you don't encrypt
the *certificate* so that it wouldn't be useful

-Ekr


>