Subject: [TLS] ALPN with 0-RTT Data

From: Kyle Nekritz <[email-masked]>
Date: Wed, 12 Oct 2016 19:49:35 +0000

Currently the draft specifies that the ALPN must be "the same" as in the connection that established the PSK used with 0-RTT, and that the server must check that the selected ALPN matches what was previously used. I find this unclear if
1) the client should select and offer one (and only one) application protocol
2) the client can offer multiple protocols, but use the most preferred one offered for 0-RTT data
3) the client must send the exact same ALPN extension as in the previous connection, but must use the ALPN previously selected by the server (even if it was not the client's first offer).

To clarify this we can instead
* allow the client to offer whatever ALPN extension it wants
* define that the 0-RTT data uses the client's most preferred application protocol offer (and the server must pick this ALPN if it accepts 0-RTT), similar to using the first PSK offer if multiple are offered
* recommend that the client uses the same application protocol that was used on the previous connection.

PR: https://github.com/tlswg/tls13-spec/pull/681

Kyle

---

From: David Benjamin <[email-masked]>
Date: Wed, 12 Oct 2016 20:01:52 +0000

My interpretation was:

1. Client and server remember the previous selected ALPN protocol in the
session.

2. The client may offer whatever ALPN protocols it likes. It does not need
to match the previous offer list, though it presumably will unless you've
got a persistent session cache or so.

3. The client assumes that session's ALPN protocol was selected for
purposes of minting 0-RTT data.

4. The server must decline 0-RTT if it choses a different ALPN protocol.
This can be implemented by just doing ALPN negotiation as normal and
declining 0-RTT if the result does not match. (If client and server prefs
have not changed, 0-RTT will work. If prefs have changed, 0-RTT will miss
but future sessions will start being 0-RTT-able. I think this is probably
the sanest behavior.)

5. The client performs the usual checks on the selected ALPN protocol (must
be one of the advertised ones). In addition, it enforces that, if 0-RTT was
accepted, the protocol must match the session one.

Pinning on the most preferred one causes awkward transitions when the most
preferred ALPN protocol is not the same as the most commonly deployed one.
If we ever define, say, h3, we want that one in front of h2 presumably, but
we wouldn't want to lose 0-RTT against all the h2 servers out there.

I don't think we should be reorder preferences based on the sessions we are
offering. That makes it much harder to reason about the behavior of
preference lists.

David

On Wed, Oct 12, 2016 at 3:49 PM Kyle Nekritz <[email-masked]> wrote:

Currently the draft specifies that the ALPN must be "the same" as in the
connection that established the PSK used with 0-RTT, and that the server
must check that the selected ALPN matches what was previously used. I find
this unclear if

1) the client should select and offer one (and only one) application
protocol

2) the client can offer multiple protocols, but use the most preferred one
offered for 0-RTT data

3) the client must send the exact same ALPN extension as in the previous
connection, but must use the ALPN previously selected by the server (even
if it was not the client's first offer).

* define that the 0-RTT data uses the client's most preferred application
protocol offer (and the server must pick this ALPN if it accepts 0-RTT),
similar to using the first PSK offer if multiple are offered

* recommend that the client uses the same application protocol that was
used on the previous connection.

Kyle

_______________________________________________

TLS mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Oct 2016 13:03:17 -0700

On Wed, Oct 12, 2016 at 1:01 PM, David Benjamin <[email-masked]>
wrote:

> 5. The client performs the usual checks on the selected ALPN protocol
> (must be one of the advertised ones). In addition, it enforces that, if
> 0-RTT was accepted, the protocol must match the session one.
>

This matches the behavior I intended in the spec (and the one NSS
implements).

-Ekr

> I don't think we should be reorder preferences based on the sessions we
> are offering. That makes it much harder to reason about the behavior of
> preference lists.
>
> David
>
>

---

From: Kyle Nekritz <[email-masked]>
Date: Wed, 12 Oct 2016 21:05:59 +0000

Reordering the ALPN offer has a couple advantages:
* It explicitly defines the protocol that the 0-RTT data is using on that connection. Without this, both the client and the server must independently store the ALPN in use (of course the server can put it in the ticket). While this should work if implemented properly, there is nothing in the protocol that enforces they match before the server accepts the data. If the client ALPN offer does happen to change, it’s even possible for the selected ALPN to be one that the client didn’t even offer.
* If the client knows out-of-band (or learns over the application protocol) that the server supports multiple protocols, it will not be able to use its current connection to start up a 0-RTT connection over the new protocol.
* I think realistically for many clients the protocol used to send 0-RTT data will end up being the only protocol that can be used on that connection, even if 0-RTT is rejected. Rejected 0-RTT data can’t be resent 1-RTT if a different application protocol is used, and it’s difficult API-wise to tell the higher layer “Your http/2 early data failed, but you can send http/1.1 requests if you want”. Thus it makes sense for these clients to advertise the 0-RTT data’s application protocol as the most preferred.

I’m not sure how this makes protocol transitions awkward. I’d still expect clients to choose the application protocol that was previously negotiated, so preferring h3 wouldn’t cause all h2 0-RTT to go away.

Kyle

From: Eric Rescorla [mailto:[email-masked]]
Sent: Wednesday, October 12, 2016 4:03 PM
To: David Benjamin <[email-masked]>
Cc: Kyle Nekritz <[email-masked]>; [email-masked]
Subject: Re: [TLS] ALPN with 0-RTT Data

On Wed, Oct 12, 2016 at 1:01 PM, David Benjamin <[email-masked]<mailto:[email-masked]>> wrote:
My interpretation was:

1. Client and server remember the previous selected ALPN protocol in the session.

2. The client may offer whatever ALPN protocols it likes. It does not need to match the previous offer list, though it presumably will unless you've got a persistent session cache or so.

3. The client assumes that session's ALPN protocol was selected for purposes of minting 0-RTT data.

4. The server must decline 0-RTT if it choses a different ALPN protocol. This can be implemented by just doing ALPN negotiation as normal and declining 0-RTT if the result does not match. (If client and server prefs have not changed, 0-RTT will work. If prefs have changed, 0-RTT will miss but future sessions will start being 0-RTT-able. I think this is probably the sanest behavior.)

5. The client performs the usual checks on the selected ALPN protocol (must be one of the advertised ones). In addition, it enforces that, if 0-RTT was accepted, the protocol must match the session one.

This matches the behavior I intended in the spec (and the one NSS implements).

-Ekr

Pinning on the most preferred one causes awkward transitions when the most preferred ALPN protocol is not the same as the most commonly deployed one. If we ever define, say, h3, we want that one in front of h2 presumably, but we wouldn't want to lose 0-RTT against all the h2 servers out there.

I don't think we should be reorder preferences based on the sessions we are offering. That makes it much harder to reason about the behavior of preference lists.

David

On Wed, Oct 12, 2016 at 3:49 PM Kyle Nekritz <[email-masked]<mailto:[email-masked]>> wrote:
Currently the draft specifies that the ALPN must be "the same" as in the connection that established the PSK used with 0-RTT, and that the server must check that the selected ALPN matches what was previously used. I find this unclear if

Kyle

TLS mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=diBVKMBm_GJBrqBsilZWP0aN5KD9xwvXSCIDOE5-LAA&s=FuSqdY1S96Vtry63oUY7VG4b-5JRJgZYv33IoBPkAhM&e=>

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=diBVKMBm_GJBrqBsilZWP0aN5KD9xwvXSCIDOE5-LAA&s=FuSqdY1S96Vtry63oUY7VG4b-5JRJgZYv33IoBPkAhM&e=>

---

From: David Benjamin <[email-masked]>
Date: Wed, 12 Oct 2016 21:29:07 +0000

On Wed, Oct 12, 2016 at 5:07 PM Kyle Nekritz <[email-masked]> wrote:

> * It explicitly defines the protocol that the 0-RTT data is using on that
> connection. Without this, both the client and the server must independently
> store the ALPN in use
> (of course the server can put it in the ticket). While this should work if
> implemented properly, there is nothing in the protocol that enforces they
> match before the server accepts the data. If the client ALPN offer does
> happen to change, it’s even possible
> for the selected ALPN to be one that the client didn’t even offer.
>

The client shouldn't offer 0-RTT on a session which predicts an ALPN that
it doesn't accept. This is consistent with the client not wanting to offer
session that uses a cipher it doesn't support. That is illegal already.

(Note clients already must have code for checking if an ALPN is acceptable
because that's what happens when a server responds. The nice thing about
the session-remembering algorithm is it involves no new codepaths apart
from a simple equality check. Clients offer parameters and confirm
acceptability of a single one, servers select given an offer.)

> * If the client knows out-of-band (or learns over the application
> protocol) that the server supports multiple protocols, it will not be able
> to use its current connection to
> start up a 0-RTT connection over the new protocol.
>

Why wouldn't it have negotiated that protocol over ALPN originally? One
should not need 0-RTT to unlock ALPN protocols.

> * I think realistically for many clients the protocol used to send 0-RTT
> data will end up being the only protocol that can be used on that
> connection, even if 0-RTT is rejected.
> Rejected 0-RTT data can’t be resent 1-RTT if a different application
> protocol is used, and it’s difficult API-wise to tell the higher layer
> “Your http/2 early data failed, but you can send http/1.1 requests if you
> want”. Thus it makes sense for these clients
> to advertise the 0-RTT data’s application protocol as the most preferred.
>

ALPN protocol switching (or any other connection property) on 0-RTT rejects
is always something a client must account for. I think your proposal has
the same problem. Perhaps the server had to turn h2 off for some reason.
You cannot assume the server's configuration remains unchanged. It is an
excellent prediction, but it is only a prediction.

A 0-RTT reject for a client ultimately must look like a retry. Everything
you ever wrote on the socket was discarded. It also must be bubbled up
sufficiently high that all connection properties are allowed to change.
This is pretty much fundamental to the whole idea of predicting
server-selected parameters. (If TLS were server-offer/client-select like
QUIC it would be a bit more obvious what's going on, but it's still the
same deal.)

For instance, here's an implementation strategy for socket-pooling clients
(i.e. browsers): you tell the HTTP layer to try again completely from the
top, meanwhile taking the socket and returning it to the socket pool as a
1-RTT-capable socket. The retry will grab that socket and use it. (Or maybe
some other request else will. That sounds weird, but it's no different from
what socket pools already do. A 0-RTT reject means the socket is reset.)

> I’m not sure how this makes protocol transitions awkward. I’d still expect
> clients to choose the application protocol that was previously negotiated,
> so preferring h3 wouldn’t
> cause all h2 0-RTT to go away.
>

They either go away or you pin on h2 when you should have gone to h3.
Suppose I prefer h3 > h2 and I talk to an h2 server. Per your proposal, if
I attempt to 0-RTT with that session, my choices are:

1. Keep my order h3 > h2. That means 0-RTT is conditioned on the server
picking h3 and I cannot 0-RTT.
2. Swap the order h2 > h3. That means 0-RTT works, but if the server then
gets upgraded to support h3, my order is false and the server continues to
pick h2. Since the server is going to continually issue me new tickets,
I'll never get the order switched back unless I go long periods without
talking to it.

With the session-remembering interpretation, once the server's preferences
change, you 0-RTT miss once. (Because your prediction is wrong... that's
unavoidable. The server's configuration changed.) But after that, all your
new tickets are at h3 and the steady state is 0-RTT-capable again.

David

>
>
> Kyle
>
>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
>
>
> *Sent:* Wednesday, October 12, 2016 4:03 PM
>
> *To:* David Benjamin <[email-masked]>
>
> *Cc:* Kyle Nekritz <[email-masked]>; [email-masked]
>
> *Subject:* Re: [TLS] ALPN with 0-RTT Data
>
>
>
>
>
>
>
>
>
>
> have not changed, 0-RTT
> will work. If prefs have changed, 0-RTT will miss but future sessions will
> start being 0-RTT-able. I think this is probably the sanest behavior.)
>
>
>
>
>
>
>
> we wouldn't
> want to lose 0-RTT against all the h2 servers out there.
>
>
>
>
>
>
>
> must check that the selected ALPN matches what was previously
> used. I find this unclear if
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=diBVKMBm_GJBrqBsilZWP0aN5KD9xwvXSCIDOE5-LAA&s=FuSqdY1S96Vtry63oUY7VG4b-5JRJgZYv33IoBPkAhM&e=>
>
>
>
>
>
>
>
>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=diBVKMBm_GJBrqBsilZWP0aN5KD9xwvXSCIDOE5-LAA&s=FuSqdY1S96Vtry63oUY7VG4b-5JRJgZYv33IoBPkAhM&e=>
>
>
>
>
>
>
>
>