Re: [TLS] ALPN with 0-RTT Data

[David Benjamin <[e-mail]>]

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 <[e-mail]> 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).



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



_______________________________________________

TLS mailing list

[e-mail]

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