Re: [quicwg/base-drafts] Rejection of 0-RTT: start over? (#761)

[Ryan Hamilton <[e-mail]>]

On Tue, Sep 5, 2017 at 6:00 PM, Martin Thomson <[e-mail]>
wrote:

> If 0-RTT is rejected should the client:
>
>    1. start over at the application layer
>    2. close all streams that it initiated (can't do that because stream 1
>    is special)
>    3. just pretend that the packets were lost and need retransmission
>
> Previously, people (@RyanAtGoogle <https://github.com/ryanatgoogle>)
> advocated for 3. So far the preponderance of feedback on the list has been
> in favour of 1, which is at least consistent with the approach in TLS.
>
​Yeah, we do #3 in Google's QUIC implementation which is super simple. Yay
for simple. Until recently I thought everyone should just do the simple
thing.

Alas, it can also be incorrect :(​ In particular, if there are any
properties of the request which depend on the connection's key (for example
Token Binding headers) then they will not be updated to reflect the new
keys. So in our implementation we're going to eventually move away from #3.

That being said, can you clarify the difference between 1 and 2? For
example, in the case of HTTP over QUIC using Token Binding, we need to
request headers to be regenerated which (in the case of Chrome's network
stack) means that the request needs to be restarted up in the application
and hence. Would this be an example of 1 or 2? (2 could definitely work,
but I'm not sure I understand the details of 1)


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/761#issuecomment-330863379