Re: [TLS] Encrypting ALPN and other unused extensions

Why is there no need for the TLS stack to use this information?  If SNI is enabled, it can be what the server uses to select the certificate and possibly the cipher it chooses to use on servers where IP space is limited.  In your example, the dispatch server needs to use SNI (if not using distinguishable VIPs) in order to relay to the other machines.  Cipher selection and certificate presentation is part of TLS, and SNI can be used as a selector for both.  Additionally, Michael is correct in that ALPN could be used in the certificate selection process, but also in the cipher selection process.  If the argument is that the application is really the layer that is using this information to inform the TLS layer what to do next, then that is semantics and hard to argue.  But the intent is the same.  SNI and ALPN can be used to alter the path the rest of the handshake takes (and for many hosts, will be the case).

-----Original Message-----
From: Martin Rex [mailto:mrex@sap.com] 
Sent: Friday, April 25, 2014 1:36 PM
To: Michael D'Errico
Cc: tls@ietf.org
Subject: Re: [TLS] Encrypting ALPN and other unused extensions

Michael D'Errico wrote:
> Watson Ladd wrote:
> > 
> > Some extensions aren't used by the TLS layer, like ALPN.
> 
> ALPN is used by the TLS layer.  The requested protocol is one of 
> several inputs to a server's certificate selection algorithm, along 
> with the SNI.

I agree that the information is conveyed within the TLS protocol, so the TLS stack may need to be able to pass this information between TLS stack an application, but there is no need that the TLS stack uses this information for anything.

With TLS extension SNI, the server side TLS stack might even completely ignore the information, i.e. not implement it.

A Hosting provider could set up an SNI-aware load balancer and dispatch/NAT incoming TLS sessions in opaque fashion to individual TLS servers, and the individual server can just ignore the contents of TLS extension SNI (or may not even implement it), and virtual hosting would still work just fine.  There would be no server name confirmantion in ServerHello extensions, but that is a quite irrelevant part of TLS extension SNI.

-Martin

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls