On Wed, Oct 17, 2018 at 4:41 PM Martin Rex <m...@sap.com> wrote: > Eric Rescorla <e...@rtfm.com> wrote: > > Martin Rex <m...@sap.com> wrote: > > > > > Sean Turner <s...@sn3rd.com> 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 > > Nope, I've raised this *EVERY* time on the list when the dead horse was > newly beaten. >
And there have been multiple consensus calls to the contrary, so this is just re-raising a decided issue. >> 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. > > Please give a clear deterministic algorithm how a client can > tell apart a server that requires cleartext SNI from a server > that does not want cleartext SNI. > This isn't really the relevant question, as there are many servers now which do not require SNI. The relevant question is how a client can be made aware that a server does support ESNI and can have high confidence that it will accept it. Such an algorithm is provided in: https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-4 Note that as explained in detail, it is not necessary that all clients send ESNI to that server. > 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. > > DNS is a non-starter for several reasons. > > Ever heard of firewalled networks, private DNS universes and HTTP CONNECT > proxies? > Yes, I've heard of all of these. They're not relevant to the question at hand. > >> 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. > > Simply to avoid a downref. I should not have to explain this to you. > > rfc2818, section 3.1: > > 3.1. Server Identity > > In general, HTTP/TLS requests are generated by dereferencing a URI. > As a consequence, the hostname for the server is known to the client. > If the hostname is available, the client MUST check it against the > server's identity as presented in the server's Certificate message, > in order to prevent man-in-the-middle attacks. > > rfc6066, section 3: > > 3. Server Name Indication > > TLS does not provide a mechanism for a client to tell a server the > name of the server it is contacting. It may be desirable for clients > to provide this information to facilitate secure connections to > servers that host multiple 'virtual' servers at a single underlying > network address. > > > It looks blatantly obvious to me that > rfc2818: "check the hostname of the server agains the server's identity > as presented in the server's Certifcate messag" > and > rfc6066: "a mechanism for a client to tell a server the name of the > server > it is contacting" > It may be obvious to you, but I don't believe it's correct. For instance, the server might be using some form of certificates other than X.509. > 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. > > Actually, no, it will not work at all in TLSv1.2 > (this would not be TLSv1.2 anymore, or an entirely different TLS extension) > > My server-side implementation of TLS extension SNI is entirely outside > of the TLS protocol stack. This is actually quite compatible with the encrypted SNI mechanism specified in draft-ietf-tls-esni, because it was designed to work with split architectures. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
