#x27;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:e...@rtfm.com]
>
>
> *Sent:* Wednesday, October 12, 2016 4:03 PM
>
> *To:* David
go away.
Kyle
From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Wednesday, October 12, 2016 4:03 PM
To: David Benjamin
Cc: Kyle Nekritz ; tls@ietf.org
Subject: Re: [TLS] ALPN with 0-RTT Data
On Wed, Oct 12, 2016 at 1:01 PM, David Benjamin
mailto:david...@chromium.org>> wro
On Wed, Oct 12, 2016 at 1:01 PM, David Benjamin
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 pres
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. T
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) ap
