Re: [TLS] Encrypting ALPN and other unused extensions

On Fri, Apr 25, 2014 at 11:20 AM, Gero, Charlie <cgero@akamai.com> wrote:
> 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).

For SNI this is true. But ALPN? Remember it was introduced to handle
HTTP 2.0 vs HTTP 1.0: I don't see people rushing out to use different
certs per protocol. Authenticating services is an interesting idea,
but if I trust a host, I can trust what it tells me about which
service I connect to. (Paul Lambert asked me a related question: does
TLS ensure that I'm talking to the right *port*? A quick read of RFC
5246 indicates it doesn't) Just because it's possible to pick a
certificate based on something, doesn't mean people do it.

Secondly, I don't like the idea of having two handshakes with
different security properties. The lower one is the only one you can
be sure you will get. I also think that forcing 1-RTT to depend on
knowing a semi-static key is unnecessary, and while browsers will do
it, it's more generally useful and so we should work to preserve it
for programmatic clients. (Yes, programmatic clients can use an
interface for storing these keys. However, it is more complicated than
if they do not, and makes the API a bit messy)

0-RTT requires a semi-static key: no two ways around it.

Sincerely,
Watson Ladd

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

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin