[quicwg/base-drafts] Bound 0-to-1-RTT Transition (#2466)

[Mike Bishop <[e-mail]>]

Taking a stab at @DavidSchinazi's suggested alternative.  In Tokyo, we agreed that flow control and stream IDs advertised in the server's 1-RTT packets and transport parameters don't apply to the client's 0-RTT data.

This makes two changes:
- The client was already prohibited from sending more 0-RTT packets after reaching 1-RTT ([TLS 4.9](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.4.9), "Though an endpoint might retain older keys, new data MUST be sent at the highest
currently-available encryption level.")  This adds a requirement on the server to drop 0-RTT packets with higher packet numbers than the first 1-RTT packet number from the client.
- Any increases to flow control or stream limits the server sends don't apply to 0-RTT traffic; servers SHOULD enforce the remembered values until at least one 1-RTT packet has been received.

This isn't perfect, as a malicious client could send a high numbered 1-RTT packet to unlock the flow control and save lower packet numbers for 0-RTT traffic which exceeds the initial limits, but it helps.  From discussion on the PR, it sounds like more aggressive enforcement than this is problematic for servers in multiple implementations.

Fixes #2458.
Fixes #2360.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2466

-- Commit Summary --

  * Simpler restriction on staying in 0-RTT
  * Stream counts, too

-- File Changes --

    M draft-ietf-quic-transport.md (15)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2466.patch
https://github.com/quicwg/base-drafts/pull/2466.diff

-- 
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/pull/2466