Re: [TLS] ALPN with 0-RTT Data

On Wed, Oct 12, 2016 at 1:01 PM, David Benjamin <davidben@chromium.org>
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 <knekritz@fb.com> 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
>
> TLS@ietf.org
>
> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>