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).
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). -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
