Subject: [TLS] Encrypting ALPN and other unused extensions

From: Watson Ladd <[email-masked]>
Date: Fri, 25 Apr 2014 07:53:18 -0700

Dear all,
Some extensions aren't used by the TLS layer, like ALPN. One of the
goals is to encrypt them. However, in a zero-RTT handshake this will
require knowing a server key to encrypt them with. In a one-RTT
handshake one can do the same thing.

The challenge is the case where the client knows nothing about the
server: here it cannot be encrypted until after the client hears from
the server, and since this is a negotiation, another round trip after
that.

Having the server make the offer and the client accept one fits nicely
into the 1-RTT handshake with no problems. However, this is not what
we decided to do with ALPN.

Any ideas?

Sincerely,
Watson Ladd

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Apr 2014 08:33:00 -0700

> handshake one can do the same thing.

I think you mean this, but just for clarity, 0-RTT handshakes generally
assume that the client knows the server's key, since the client is
going to encrypt data to the server in the first flight using that key.

> we decided to do with ALPN.

It's worth mentioning that this actually entails a delay for the server
in server-speaks-first protocols. I.e., in ALPN as soon as the server
has selected the protocol it can start emitting data, whereas in a
mode where the protocol selection is in the client's second flight,
the server now has to wait for it. Of course, with HTTP, because
the client speaks first, the client can piggyback the protocol
selection message on the first request.

> Any ideas?

draft-rescorla-tls13-new-flows-01 explores this a bit.

First, if the client is really totally naive about the server, then if it
wants
to do ALPN it pretty much needs to send the ALPN information in the
clear in the ClientHello, since the server might be TLS 1.2 or below
and this is the time it can send it. However, if the client believes
that the server is likely to be TLS 1.3, then there are some options...

A. If we're attempting to encrypt SNI using an anonymous DH exchange
as in Section 6, then we obviously get passive protection of the ALPN
information for free. It's more work to get active protection, but since
(a) SNI is probably more sensitive than ALPN and (b) the attacker
can generally simulate being TLS 1.2 or below for naive clients,
it's not clear how much that would help in any case.

B. If we're not attempting to encrypt SNI (or we are using something
like Andy's suggestion), then it seems like there are roughly four
options:

1. Only encrypt the server's side of the ALPN negotiation, which
contains the selection but not the client's side which contains
the offer, as in Figure 6 in:
http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#appendix-C

2. Allow only clients with previous state to encrypt the ALPN information,
in both 0-RTT and 1-RTT cases, as in Figure 3 in:
http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-6.1

3. Have some in-band mechanism for the client to discover the server's
keys, though this could be simplified from the flows in
draft-rescorla-tls-new-flows-01, since the client can reveal the SNI
in its first message and just get the server's keys then.

4. Have some out-of-band mechanism for the client to discover
a server key and then encrypt it along with the rest of the ClientHello
(basically what Andy suggested for SNI).

Obviously, you could mix-and-match these to some extent. I.e., one
could allow the client to either send the ALPN information in the clear
if it has no previous state or encrypt it if it did, with DNS being one way
to acquire said state. As Andy pointed out, the handshake state machine
and message flows would be basically the same in both cases, except
that the ClientHello would be encrypted in one and not the other.
The major drawback, of course, is that you have two otherwise
similar appearing modes with different privacy properties.

-Ekr

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 25 Apr 2014 09:27:25 -0700

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.

Mike

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Apr 2014 10:06:18 -0700

> algorithm, along with the SNI.

I knew that this was going to be a possibility, but are people
actually doing that already?

---

From: [email-masked] (Martin Rex)
Date: Fri, 25 Apr 2014 19:36:08 +0200 (CEST)

> 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

---

From: "Gero, Charlie" <[email-masked]>
Date: Fri, 25 Apr 2014 14:20:42 -0400

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:[email-masked]] 
Sent: Friday, April 25, 2014 1:36 PM
To: Michael D'Errico
Cc: [email-masked]
Subject: Re: [TLS] Encrypting ALPN and other unused extensions

Michael D'Errico wrote:
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Watson Ladd <[email-masked]>
Date: Fri, 25 Apr 2014 19:34:26 -0700

> 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 whe…

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

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Apr 2014 22:20:14 -0700

On 25 April 2014 19:34, Watson Ladd <[email-masked]> wrote:
> does TLS ensure that I'm talking to the right *port*?

That's a PKIX function, but the answer is no, mostly [RFC6125].  We
authenticate names, even though it is theoretically possible to
authenticate URIs, I don't think that it is used in many places and
there has been anything in between defined.

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 26 Apr 2014 00:37:25 -0700

Watson Ladd wrote:
>> SNI and ALPN can be used to alter the path the rest of the handshake takes (and for many hosts, will be the case).
> 
> certs per protocol.

It's a bit premature to inter ALPN when it hasn't yet been published as
an RFC.  Why don't you like it?

Mike

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 26 Apr 2014 07:48:16 -0700

On Apr 25, 2014, at 10:20 PM, Martin Thomson <[email-masked]> wrote:

> That's a PKIX function,

Not at all true.

> but the answer is no, mostly [RFC6125].  

And not even there. :-)

There are no certificate fields that specify the port on which the server is running, and even RFC 6125 only talks about services, which can (and often are) run on ports other than their "default" port. Even the widely-derided key usage field doesn't specify a port. 

> We

RFC 6125 says plenty about naming with URIs, as does the base PKIX spec; neither specifies any operational way to authenticate past the host name.

--Paul Hoffman

---

From: Watson Ladd <[email-masked]>
Date: Sun, 27 Apr 2014 09:06:07 -0700

On Sat, Apr 26, 2014 at 12:37 AM, Michael D'Errico <[email-masked]> wrote:
>>> SNI and ALPN can be used to alter the path the rest of the handshake
>>> takes (and for many hosts, will be the case).
>>
>>

"Like it"? The question is whether or not the flexibility gained from
letting the server pick its certificate in response to ALPN is worth
the cost in protocol complexity. The usecases I've seen do not involve
doing this. Remember I'm not proposing removing ALPN: I'm proposing
changing the flow to work better with 1-RTT TLS and HTTP.

Is there a cost in protocol complexity in supporting this usage? Yes.
We haven't figured out a good way to encrypt SNI for much the same
reason: how do you know what key to use to encrypt and decrypt data
that will tell you which key to use. If we want 1-RTT to require
foreknowledge of a key, this solves that problem partially, but at the
cost of complicating the implementations that want to take advantage
of 1-RTT.

Sincerely,
Watson Ladd

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 27 Apr 2014 12:55:25 -0700

Watson Ladd wrote:
> 
> I'm not proposing removing ALPN: I'm proposing

ALPN doesn't add any more protocol complexity than SNI, so I don't see
the problem.  If you can figure out a way to encrypt SNI such that the
server can use it to select a certificate, then you can also encrypt
ALPN using the same method.

Mike

---

From: Watson Ladd <[email-masked]>
Date: Sun, 27 Apr 2014 13:20:40 -0700

> ALPN using the same method.

True: we can encrypt the handshake. But that's turned out to be harder
than expected.

What if it turns out we can't encrypt SNI? We have one proposal,
relying on encrypting the handshake using a key sent over DNS. It's a
good idea, and should work. I'd like it to work. But it might not
work. I think it's worth identifying alternative designs and thinking
about them before Denver, so that if it turns out we can't encrypt
SNI, we can encrypt other extensions in need of encryption.

Sincerely,
Watson Ladd

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 28 Apr 2014 09:35:01 -0400

> work. I'd like it to work. But it might not work. I think it's worth identifying alternative designs and thinking about them before Denver, so that if it turns out we can't encrypt SNI, we can encrypt other extensions in need of encryption.

+1

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz