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

[Jana Iyengar <[e-mail]>]

janaiyengar commented on this pull request.

A few suggestions, minor.

> @@ -1422,6 +1422,16 @@ server's new preferred_address value in the handshake.
 A server MUST either reject 0-RTT data or abort a handshake if the implied
 values for transport parameters cannot be supported.
 
+A client MUST NOT use updated values it learns either from the server's updated

This is difficult to read. How about:
"When sending frames in 0-RTT packets, a client MUST only use remembered transport parameters; importantly, it MUST NOT use updated values that it learns from the server's updated transport parameters or from frames received in 1-RTT packets."

> @@ -1422,6 +1422,16 @@ server's new preferred_address value in the handshake.
 A server MUST either reject 0-RTT data or abort a handshake if the implied
 values for transport parameters cannot be supported.
 
+A client MUST NOT use updated values it learns either from the server's updated
+transport parameters or frames carried in 1-RTT when sending frames in 0-RTT
+packets.  Updated values of transport parameters from the handshake only apply

```suggestion
packets.  Updated values of transport parameters from the handshake apply only
```

> @@ -1422,6 +1422,16 @@ server's new preferred_address value in the handshake.
 A server MUST either reject 0-RTT data or abort a handshake if the implied
 values for transport parameters cannot be supported.
 
+A client MUST NOT use updated values it learns either from the server's updated
+transport parameters or frames carried in 1-RTT when sending frames in 0-RTT
+packets.  Updated values of transport parameters from the handshake only apply
+to 1-RTT packets.  For instance, flow control limits from remembered transport
+parameters apply to all 0-RTT packets even if those values are increased by the
+handshake; increased limits from frames cannot be applied, because the client

```suggestion
handshake.  Increased flow control limits from frames cannot be applied, because the client
```

> @@ -1422,6 +1422,16 @@ server's new preferred_address value in the handshake.
 A server MUST either reject 0-RTT data or abort a handshake if the implied
 values for transport parameters cannot be supported.
 
+A client MUST NOT use updated values it learns either from the server's updated
+transport parameters or frames carried in 1-RTT when sending frames in 0-RTT
+packets.  Updated values of transport parameters from the handshake only apply
+to 1-RTT packets.  For instance, flow control limits from remembered transport
+parameters apply to all 0-RTT packets even if those values are increased by the
+handshake; increased limits from frames cannot be applied, because the client

I might even suggest dropping the second half, after "increased limits from frames".

>  
 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

New paragraph -- this last sentence is not related to the earlier discussion in this para.
```suggestion
acknowledgment for a 1-RTT packet MUST be carried in a 1-RTT packet. 

A server
```

-- 
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-206646721