On Wed, Oct 17, 2018 at 07:25:38PM -0700, Eric Rescorla wrote: > >> 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.
Right -- it's not a matter of a server requiring or not requiring ESNI. The way I understand it, a server that supports ESNI merely affords clients an opportunity to better protect themselves -- it is still the client's responsibility to resist downgrades, and to somehow discover (through DNS or otherwise) that the server supports ESNI in the first place. I imagine that most servers that support ESNI will continue to simultaneously support plaintext SNI connections. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
