Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert

[Michael D'Errico <[e-mail]>]

Martin Rex wrote:
> 
> SNI is _not_ a naming service.  It is not even a part of TLS itself.

I have no idea what point you're trying to make here.  What gives you
the idea that the server name extension is not a part of TLS?  It was
a missing requirement that has been added as an extension, which is
similar to the "Host:" header of HTTP.  "Host:" was not a part of the
first HTTP specification, but its need became clear and it was added
later.  That does not mean that "Host:" is not actually a part of HTTP!

> SNI is a hint for the server application created by the client application
> and conveyed through a TLS extension.

No, it's not a "hint."  It tells the TLS layer which domain name the
client is trying to communicate with.  If you have a server that handles
more than one domain name on the same IP address, there is no other way
for the TLS layer to know which certificate chain to use in its negotia-
tion.

> RFC-5246 is pretty clear about this (last sentence of section 1):
> 
>    the decisions on [...] how to interpret the authentication certificates
>    exchanged are left to the judgment of the designers and implementors
>    of protocols that run on top of TLS. 

Yes, but it was decided that RFC 5246 would not subsume RFC 4366 (TLS
extensions), so of course RFC 5246 does not say anything about SNI.

> So a TLS server implementation that makes bold assumptions about what
> fancy things it should do with the server_name in an incoming ClientHello
> is obviously broken.  This is an application-level issue, and a TLS
> server application should not do anything unless explicitly instructed
> to do so by the calling application.  A TLS server implementation that
> attempts to be "smart" without being directed by the server application
> is violating the TLS spec and can easily cause needless interop problems.

It's apparent that you don't understand what SNI is for.  TLS absolutely
needs to know which domain name a client is trying to connect to so that
an appropriate certificate chain can be selected.  The "Host:" header
fixed HTTP so that it could handle multiple domains on a single IP
address; that and the SNI extension fix HTTPS to work for multiple
domains on a single IP address.  Nothing fancy about it, and certainly
not broken.

Mike