Subject: [quicwg/base-drafts] Allow stream-related frames in 0-RTT (#2355)

From: Martin Thomson <[email-masked]>
Date: Sun, 20 Jan 2019 21:07:48 -0800

In #2344, @kazuho suggests that we could allow RESET_STREAM in 0-RTT.
That seems slightly wrong, because why would someone send something then
give up without receiving anything in return, but that is actually
possible in the presence of packet loss.  And changing your mind is
perfectly acceptable.

But RESET_STREAM doesn't really cover it.  Streams can get blocked,
requests can go out with additional flow control credits, and maybe even
STOP_SENDING makes sense.  So this changes it so that any stream-related
frame (those that exist to convey application state or manage it), can
be sent in 0-RTT.  That seems more principled than just adding
RESET_STREAM.

Closes #2344.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Allow stream-related frames in 0-RTT

-- File Changes --

    M draft-ietf-quic-tls.md (6)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2355.patch
https://github.com/quicwg/base-drafts/pull/2355.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/2355

---

From: Marten Seemann <[email-masked]>
Date: Sun, 20 Jan 2019 21:54:44 -0800

Thede rules seem to get more and more complex. As I mentioned in the discussion on the issue, I’d prefer to allow all frames in 0-RTT. For example, what’s the harm of sending a PING in 0-RTT?

-- 
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/2355#issuecomment-455956411

---

From: ianswett <[email-masked]>
Date: Mon, 21 Jan 2019 11:54:13 -0800

ianswett commented on this pull request.

> @@ -334,9 +334,11 @@ encryption levels:
 - ACK frames MAY appear in packets of any encryption level other than 0-RTT, but
   can only acknowledge packets which appeared in that packet number space.
 
-- STREAM frames MUST ONLY appear in the 0-RTT and 1-RTT levels.
+- All stream- and flow control-related frame types (RESET_STREAM, STOP_SENDING,

Is the '-' after stream intentional?

-- 
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/2355#pullrequestreview-194743956

---

From: ianswett <[email-masked]>
Date: Mon, 21 Jan 2019 11:56:13 -0800

I'm ok with the change, but I think we should be clear that these frames are 0-RTT or 1-RTT only.

-- STREAM frames MUST ONLY appear in the 0-RTT and 1-RTT levels.
+- All stream- and flow control-related frame types (RESET_STREAM, STOP_SENDING,
+  STREAM, MAX_DATA, MAX_STREAM_DATA, MAX_STREAMS, DATA_BLOCKED,
+  STREAM_DATA_BLOCKED, and STREAM_BLOCKED) MAY appear in the 0-RTT level.

This no longer says that these MUST ONLY appear at 0-RTT and 1-RTT levels.  I think keeping that statement is helpful

-- 
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/2355#pullrequestreview-194744366

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Jan 2019 14:20:42 -0800

@martinthomson pushed 1 commit.

59580812145936f7089586212155f14f4495d49f  Expand the anti-replay story

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2355/files/449d636415a868bd503ac6334257dcb1f9bb93af..59580812145936f7089586212155f14f4495d49f

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Jan 2019 14:24:33 -0800

OK, big changes here based on doing more analysis.  Please re-review.

-- 
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/2355#issuecomment-456213958

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Jan 2019 14:25:47 -0800

f9d24ec32312d0d0328c4d9057838d5653ece8e6  Missing 'only'

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2355/files/59580812145936f7089586212155f14f4495d49f..f9d24ec32312d0d0328c4d9057838d5653ece8e6

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 21 Jan 2019 16:43:39 -0800

kazuho commented on this pull request.

As stated in 
https://github.com/quicwg/base-drafts/issues/2344#issuecomment-456233537, my preference goes to naming the frames that are necessary for 0-RTT to work rather than allowing any frames to be used (with the only exceptions being CRYPTO and ACK).

Besides, now that we have a section for Replay Attacks using 0-RTT, it might make sense to recommend servers _not_ sending MAX_DATA, MAX_STREAM_DATA, MAX_STREAMS frames until the handshake is complete. This works as a replacement of max_early_data_size that we have in TLS 1.3.

-- 
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/2355#pullrequestreview-194800021

---

From: Alessandro Ghedini <[email-masked]>
Date: Tue, 22 Jan 2019 03:51:29 -0800

ghedo requested changes on this pull request.

> @@ -326,17 +326,12 @@ encryption levels:
 
 - CRYPTO frames MAY appear in packets of any encryption level except 0-RTT.
 
-- CONNECTION_CLOSE MAY appear in packets of any encryption level other than

Section 10.3 of the transport draft says that if 1-RTT keys are not available, CONNECTION_CLOSE can be sent in Initial and Handshake, but if I read this right, this change means that CONNECTION_CLOSE can only be sent in 1-RTT and 0-RTT?

-- 
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/2355#pullrequestreview-194965840

---

From: ianswett <[email-masked]>
Date: Tue, 22 Jan 2019 04:24:24 -0800

I think the additional text on replay is helpful, but the Kazuho makes an interesting point about only allowing specific frames in 0-RTT and not allowing MAX_DATA.

 

Given we can't stateless reset the connection until the handshake is complete, I really want to continue allowing CONNECTION_CLOSE in Initial and Handshake.

-- 
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/2355#pullrequestreview-194976645

---

From: Nick Banks <[email-masked]>
Date: Tue, 22 Jan 2019 06:37:20 -0800

nibanks approved this pull request.

Generally looks good. Just need to make sure CONNECTION_CLOSE is allowed everywhere.

 

+1, I feel like we've had this discussion several times and all agreed that CONNECTION_CLOSE needs to be allowed in Initial and Handshake packets.

-- 
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/2355#pullrequestreview-195035752

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Jan 2019 11:33:09 -0800

martinthomson commented on this pull request.

 

Arghh, I need to revert this one.

-- 
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/2355#discussion_r249929384

---

From: Mike Bishop <[email-masked]>
Date: Tue, 22 Jan 2019 11:51:49 -0800

As @marten-seemann notes, there is a reasonable argument on the issue that most frame should simply be permitted.  Would it make more sense to invert the list and instead state only where frames are prohibited?

-- 
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/2355#issuecomment-456538874

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Jan 2019 13:25:59 -0800

0fe91c8cb89eed4b0a63b5994c7287933d37a54c  Fix CONNECTION_CLOSE

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2355/files/f9d24ec32312d0d0328c4d9057838d5653ece8e6..0fe91c8cb89eed4b0a63b5994c7287933d37a54c

---

From: ianswett <[email-masked]>
Date: Wed, 30 Jan 2019 22:56:13 -0800

ianswett approved this pull request.

LGTM, one nit.

> @@ -324,19 +324,15 @@ the connection can usually appear at any encryption level, whereas those
 associated with transferring data can only appear in the 0-RTT and 1-RTT
 encryption levels:
 
-- CRYPTO frames MAY appear in packets of any encryption level except 0-RTT.
-
-- CONNECTION_CLOSE MAY appear in packets of any encryption level other than
-  0-RTT.
+- CRYPTO and CONNECTION_CLOSE frames MAY appear in packets of any encryption
+  level except 0-RTT.
 
 - PADDING frames MAY appear in packets of any encryption level.

nit: I'd put the most permissive statement(this one) first

-- 
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/2355#pullrequestreview-198445391

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jan 2019 23:43:28 -0800

fdfb19d5922e75b5d6b93eda217e3a9c242308f6  Move PADDING up

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2355/files/0fe91c8cb89eed4b0a63b5994c7287933d37a54c..fdfb19d5922e75b5d6b93eda217e3a9c242308f6