On Wed, Oct 17, 2018 at 10:03 AM Martin Rex <[email protected]> wrote: > Sean Turner <[email protected]> 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 >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
