Subject: [quicwg/base-drafts] No reading of 1-RTT before the handshake is complete (#3224)

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Nov 2019 18:55:20 -0800

We really REALLY mean it.

The effect of #3159 has been to shame some implementations into the
right behaviour, but on reviewing this section, it really was
unambiguous.  This tweaks the text slightly and adds a cautionary note,
but it is otherwise unchanged other than a few editorial tweaks.

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

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

-- Commit Summary --

  * No reading of 1-RTT before the handshake is complete

-- File Changes --

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

-- Patch Links --

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

---

From: Marten Seemann <[email-masked]>
Date: Mon, 11 Nov 2019 19:40:35 -0800

marten-seemann commented on this pull request.

I agree that this solves the issue **IF** implementations adhere to the spec.

A change of the key schedule that would make it impossible to use 1-RTT keys before the completion of the handshake would still be my preferred solution of this issue. I'm not sure if this isn't out of scope though.

>  - Any received 0-RTT data that the server responds to might be due to a replay
-attack.
-
-Therefore, the server's use of 1-RTT keys is limited before the handshake is
-complete.  A server MUST NOT process data from incoming 1-RTT
-protected packets before the TLS handshake is complete.  Because
-sending acknowledgments indicates that all frames in a packet have been
-processed, a server cannot send acknowledgments for 1-RTT packets until the
-TLS handshake is complete.  Received packets protected with 1-RTT keys MAY be
-stored and later decrypted and used once the handshake is complete.
+  attack.
+
+Therefore, the server's use of 1-RTT keys MUST be limited to sending data before
+the handshake is complete.  A server MUST NOT process data from incoming 1-RTT

Why not: "A server MUST NOT process incoming 1-RTT protected 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/3224#pullrequestreview-315278261

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Nov 2019 20:59:30 -0800

@martinthomson pushed 1 commit.

4434e4000805050a39011a5c013e8828e3707009  Simplify

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3224/files/2ff0f2bccca8f6271a133a278a0496be5be144f7..4434e4000805050a39011a5c013e8828e3707009

---

From: ianswett <[email-masked]>
Date: Tue, 12 Nov 2019 12:37:25 -0800

ianswett approved this pull request.

-- 
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/3224#pullrequestreview-315826050

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 13 Nov 2019 08:10:36 -0800

kazuho approved this pull request.

Looks good. I like the idea of having normative text (MUST NOT) for 1-RTT packets, because that is a QUIC-specific requirement.

-- 
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/3224#pullrequestreview-316365301

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 18 Nov 2019 18:38:39 -0800

janaiyengar commented on this pull request.

> @@ -1171,27 +1171,34 @@ Note:
 ## Receiving Out-of-Order Protected Frames {#pre-hs-protected}
 
 Due to reordering and loss, protected packets might be received by an endpoint
-before the final TLS handshake messages are received.  A client will be unable
-to decrypt 1-RTT packets from the server, whereas a server will be able to
-decrypt 1-RTT packets from the client.
+before the final TLS handshake messages are received.  Each endpoint MUST NOT
+decrypt 1-RTT packets from its peer prior to completing the handshake.

I'd leave the old text in for emphasis, and also a minor edit: "A client will be unable to decrypt 1-RTT packets from the server, whereas a server will be able to decrypt 1-RTT packets from the client. Both endpoints MUST NOT decrypt 1-RTT  packets from their peers prior to completing the 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/3224#pullrequestreview-318753700

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 18 Nov 2019 18:39:03 -0800

Meh. Both/Each, they're both sucky here.

-- 
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/3224#discussion_r347707369

---

From: Martin Thomson <[email-masked]>
Date: Mon, 18 Nov 2019 18:44:50 -0800

@martinthomson pushed 14 commits.

63c764b0ccab1aa5ad4eef8fc78fa6467f6edd5f  [HTTP/3] [editorial] How many parts is the HTTP/3 specification is split into exactly? (#3219)
110fcb3e628c2142c76df76cf194fda1382d2de8  [HTTP/3] [editorial] Remove mention of redefining setting format. (#3220)
3710ed6f8599c1c9cdd3eb1e259760a0afc5f424  App or flow control limited (#3238)
8bae30acd2c4058dd7108eca972c90039c91d688  Fix Gorry's editorial comments (#3237)
9a5786a1ab4538d01e403ee3b42fa086878226f2  Update draft-ietf-quic-recovery.md
97c70d33e85c44b559b8dc1069c0f5a7d1635b1e  Reference 3168 for ECN
6ed0fdab6286a3bbf3a74441c9a8defd76f9483a  Update draft-ietf-quic-recovery.md
65d42c7e0d4168421972e4b1631a47ee3ee0583b  ECN editorial
2afe57df1e104e39a7487854b9c79f22498b5a17  Fix incorrect expression
37f2a1949b73d871f5801e9da9fc03c9d8337632  Set, not seed
68466780a9be9543e6720303648da735f635cb8b  Jana's suggestion
d8d51c6019bc1be35f96112529b874ee9a592a85  endpoints never requests a CID
4a23a94c76b1ff6af57bcda6c58accd088fad50f  Avoid using table- prefixes for anchors
00bbd927b8e03887fd66e72f751886b4c75d6006  Keep context

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3224/files/4434e4000805050a39011a5c013e8828e3707009..00bbd927b8e03887fd66e72f751886b4c75d6006

---

From: MikkelFJ <[email-masked]>
Date: Tue, 19 Nov 2019 01:59:44 -0800

I know this has been discussed before - but reading the text as it is I wonder:

the text mixes three different terms, seeming arbitrarily: decryption of 1-RTT, processing of 1-RTT, and reading 1-RTT packets, and not using the 1-RTT keys at all.

I can see how packets MUST not be processed ahead of time, but I don't see why the keys cannot be used to qualify the packets. In fact the text says you can store 1-RTT packets until ready, but how do you know they are indeed 1-RTT packets if you cannot use the keys in some form?

There is a related concern about timing attacks if you do not both decrypt and verify but if that is not topic here, and if it is a concern it should probably be mentioned or referenced.

-- 
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/3224#issuecomment-555427392