Re: [TLS] Encrypting ALPN and other unused extensions

[Eric Rescorla <[e-mail]>]

On Fri, Apr 25, 2014 at 7:53 AM, Watson Ladd <[e-mail]> wrote:

> 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.
>

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.


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.
>

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