Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Eric Rescorla <[e-mail]>]

On Sat, Oct 29, 2016 at 5:23 AM, Martin Rex <[e-mail]> 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
>