Re: [quicwg/base-drafts] 0-RTT can't use transport parameters or 1-RTT frames (#2461)

[Mike Bishop <[e-mail]>]

MikeBishop approved this pull request.

Other than thinking our enforcement guidance should be a bit stronger, I think this is okay.  It expresses the correct principles.

>  
 A client SHOULD instead generate a fresh cryptographic handshake message and
 start packet numbers from 0.  This ensures that new 0-RTT packets will not use
 the same keys, avoiding any risk of key and nonce reuse; this also prevents
 0-RTT packets from previous handshake attempts from being accepted as part of
 the connection.
 
+A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets
+from the server.  This means that 0-RTT packets cannot contain any response to
+frames from 1-RTT packets.  For instance, a client cannot send an ACK frame in a
+0-RTT packet, because that can only acknowledge a 1-RTT packet.  An
+acknowledgment for a 1-RTT packet MUST be carried in a 1-RTT packet.
+
+A server MAY treat a violation of remembered limits as a connection error of an

```suggestion
A server SHOULD treat a violation of remembered limits as a connection error of an
```
Per previous comment, I believe the outcome from Tokyo was to recommend enforcement.  Subsequent discussion has concluded that thorough enforcement might be too heavy-weight, but the specific flow-control approach is simple enough and ought to still be recommended.

-- 
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/2461#pullrequestreview-228515248