Subject: [quicwg/base-drafts] Remove EndOfEarlyData from TLS (#1792)

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 16:33:26 -0700

As discussed in NYC, this message doesn't help us in QUIC, and it's annoying to implement.

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

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

-- Commit Summary --

  * Remove EndOfEarlyData from TLS

-- File Changes --

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

-- Patch Links --

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

---

From: ianswett <[email-masked]>
Date: Mon, 24 Sep 2018 16:47:34 -0700

ianswett commented on this pull request.

Q: Is "CRYPTO frames MAY appear in packets of any encryption level." still accurate?

Also, I think we can be more explicit about when to discard 0RTT read keys on the server side in "Discarding Unused Keys" now that no 0RTT packets are expected to have larger packet numbers than 1RTT 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/1792#pullrequestreview-158335884

---

From: ianswett <[email-masked]>
Date: Mon, 24 Sep 2018 16:49:05 -0700

Both of those comments were about the transport doc, so if you wanted to update that in a separate PR, that SGTM.

-- 
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/1792#issuecomment-424161901

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 16:57:05 -0700

@martinthomson pushed 1 commit.

5ad418c  CRYPTO can't appear at 0-RTT any more

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1792/files/4a58e88d242f1763c113aaf90c835e10e4e567c9..5ad418c195b37149b693ef69a107dad72db95ed0

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 17:01:52 -0700

05f5516  Discarding 0-RTT keys is more complicated now

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1792/files/5ad418c195b37149b693ef69a107dad72db95ed0..05f5516145ce8378dedf9f0a0b19677ea0200803

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 17:02:10 -0700

Both of those are in the TLS doc as it happens, so I thought it best to address them here.  Thanks for catching them.

-- 
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/1792#issuecomment-424164031

---

From: Subodh Iyengar <[email-masked]>
Date: Mon, 24 Sep 2018 19:42:38 -0700

siyengar commented on this pull request.

> @@ -1108,6 +1108,16 @@ and reliance on them should be minimized.  However, any tampering with the
 parameters will cause the handshake to fail.

+## Removing the EndOfEarlyData Message {#remove-eoed}
+
+Negotiating the quic_transport_parameters extension also modifies TLS to remove

this makes it seem like sending quic_transport_params on a tcp connection will also negotiate having no eoed. Is that really desirable. Maybe we should say that this should be only done when  both endpoints know they are speaking quic.

-- 
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/1792#pullrequestreview-158360953

---

From: ianswett <[email-masked]>
Date: Tue, 25 Sep 2018 00:37:11 -0700

> @@ -465,10 +465,9 @@ and lower encryption levels than the current encryption level used by TLS.
 
 In particular, server implementations need to be able to read packets at the
 Handshake encryption level before the final TLS handshake message at the 0-RTT

What's the final TLS handshake message at the 0-RTT encryption level?  Overall, I'm not sure what this paragraph is trying to add to the previous 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/1792#pullrequestreview-158410043

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Sep 2018 10:56:04 -0700

ace1ee1  Don't allow this with TCP

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1792/files/05f5516145ce8378dedf9f0a0b19677ea0200803..ace1ee19a3c83530e1ec32d5c330f12deb48dfe1

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Sep 2018 17:57:29 +0000 (UTC)

44bc656  Snafu regarding 0-RTT and handshake interleaving

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1792/files/ace1ee19a3c83530e1ec32d5c330f12deb48dfe1..44bc6568d55b21352228a62948d9f6560a4d86e6

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 25 Sep 2018 18:06:54 +0000 (UTC)

kazuho commented on this pull request.

> @@ -1107,6 +1107,21 @@ of the handshake, they cannot be fully trusted until the handshake completes,
 and reliance on them should be minimized.  However, any tampering with the
 parameters will cause the handshake to fail.
 
+Endpoints MUST NOT send this extension in a TLS connection that does not use
+QUIC (such as the use of TLS with TCP defined in {{!TLS13}}).  A fatal
+unsupported_extension alert MUST be sent if this extension is received when the
+transport is not QUIC.
+
+
+## Removing the EndOfEarlyData Message {#remove-eoed}
+
+Negotiating the quic_transport_parameters extension also modifies TLS to remove
+the EndOfEarlyData message.  QUIC does not rely on this message to mark the end

My preference goes to simply stating that we do not use EOED in QUIC, rather than stating that the use of a particular extension signals the omission (I assume that is what @siyengar suggested).

My read is that the proposed text expects the stacks to be implemented in either of the following two ways, which seems like an unnecessary complication to me:
* making TLS stacks depend on an extension defined outside of TLS
* let the server-side QUIC stack modify the flag of the TLS stack (signaling the omission) when it processes ClientHello

-- 
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/1792#pullrequestreview-158673698

---

From: MikkelFJ <[email-masked]>
Date: Tue, 25 Sep 2018 11:41:47 -0700

mikkelfj commented on this pull request.

I share those thoughts - while it is unlikely that a random TCP connection would send a QUIC extension, QUIC cannot mandate what other protocols should and should not do. Furthermore, a QUIC client might not know for sure that what the other end supports, and even if it thinks that it does, the might not remain true after a random intern pushed the wrong button.

-- 
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/1792#discussion_r220309530

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Sep 2018 15:34:59 -0700

Merged #1792 into master.

-- 
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/1792#event-1867031673