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

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Apr 2019 18:33:32 -0700

@martinthomson pushed 1 commit.

9ff2ebf35b10389ef9395fed1118f5de13dd06bc  Editorial comments from @janaiyengar

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2461/files/1c9fcc313fa887226283627b0e9fa0916a9c8942..9ff2ebf35b10389ef9395fed1118f5de13dd06bc

---

From: ianswett <[email-masked]>
Date: Wed, 10 Apr 2019 06:53:11 -0700

ianswett approved this pull request.

Still LGTM

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

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 12 Apr 2019 16:36:19 -0700

janaiyengar approved this pull request.

Yup, this LGTM.

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

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 13 Apr 2019 09:30:04 -0700

kazuho approved this pull request.

LGTM modulo below.

> @@ -1422,6 +1422,15 @@ 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.
 
+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.  Updated values of transport parameters from the handshake apply only
+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 or by frames send in 1-RTT packets.  A server MAY treat use of updated

s/send/sent/?

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

---

From: Martin Thomson <[email-masked]>
Date: Sat, 13 Apr 2019 14:05:43 -0700

ed6a8795f9add34d02b9b3df31dd1f0fe3d50950  s/send/sent

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2461/files/9ff2ebf35b10389ef9395fed1118f5de13dd06bc..ed6a8795f9add34d02b9b3df31dd1f0fe3d50950

---

From: Mike Bishop <[email-masked]>
Date: Thu, 18 Apr 2019 14:29:45 -0700

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Apr 2019 21:40:37 +0000 (UTC)

0944d13bb4c768b231119bcaf3768027eb0e8e24  recommend enforcement of 0-RTT flow control

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2461/files/ed6a8795f9add34d02b9b3df31dd1f0fe3d50950..0944d13bb4c768b231119bcaf3768027eb0e8e24

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Apr 2019 14:43:40 -0700

5154c38410356713c88d017289c7014ce1b3c591  Merge branch 'master' into 0rtt-cant-respond-to-1rtt

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2461/files/0944d13bb4c768b231119bcaf3768027eb0e8e24..5154c38410356713c88d017289c7014ce1b3c591

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Apr 2019 14:46:14 -0700

f661b8b15fa1bba2f479a99a29dfb75a5d5534d1  Wrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2461/files/5154c38410356713c88d017289c7014ce1b3c591..f661b8b15fa1bba2f479a99a29dfb75a5d5534d1