On Sat, Oct 29, 2016 at 5:23 AM, Martin Rex <m...@sap.com> wrote: > If the server_name remains in plaintext and full sight in ClientHello > (where it needs to be for TLSv1.2 backwards compatibility anyway), > then I don't have an issue. (I'm sorry for not reading the draft in full)
Good to hear. > Eric Rescorla wrote: > > > >> (2) hiding of the TLS extension SNI. > >> Right now it is perferctly fine to implement TLS extensions SNI > >> on the server completely outside the TLS protocol stack to route > >> to single-cert SNI-unaware backends. The current proposal > >> suggest to move TLS extension SNI into the encrypted part, if > >> my superficial reading of the draft is correct, so TLSv1.3 > >> will not fly with existing architectures where spreading of > >> TLS requests on the server-side based on TLS extension SNI > >> is done outside of the TLS protocol stack (i.e. bottleneck-less > >> without having to open TLS). > > > > > > This isn't quite right. In RFC 6066, the client sends its server_name > > extension in ClientHello and the server responds with an empty > > server_name in its ServerHello to indicate that it accepted SNI. > > Yes, I know that rfc6066 suggests the server responds with an empty SNI > extension. This kind of server response is is a complete waste, > and server-side SNI works just fine with the server not returning > an empty SNI extension. > > > > > > A server that receives a client hello containing the "server_name" > > extension MAY use the information contained in the extension to guide > > its selection of an appropriate certificate to return to the client, > > and/or other aspects of security policy. In this event, the server > > SHALL include an extension of type "server_name" in the (extended) > > server hello. The "extension_data" field of this extension SHALL be > > empty. > > > > In TLS 1.3, the client's extension remains where it is, but the server's > > extension is in EncryptedExtensions. This shouldn't interfere with > > configurations such as the one you describe, as the server already > > needed to insert the SNI field itself and hash it into Finished. > > Nope, the server doesn't need to insert anything at all. The empty > TLS extensions SNI in ServerHello is completely superflouous. > > If this is really about "hinding the empty TLS extension SNI response", > while leaving the actualy server_name in full sight in the cleartext > ClientHello, why not just dropping the ServerHello TLS extension SNI > response and be done with it? It really has no functional value other > than information discovery for scanners (the bad guys). > I would be fine with that if others are. Here's how we got here: - RFC 6066 requires it (it's a SHALL level requirement). - We didn't see a need to update the semantics of 6066 - Everything that doesn't have to be in ServerHello goes into EE. If point #2 is wrong, then that's easy to change, though it would be a change to implementations. NSS, for instance, sends it: http://searchfox.org/nss/source/lib/ssl/ssl3ext.c#436 -Ekr > > -Martin >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
