Subject: Re: [quicwg/base-drafts] Prohibit TLS 1.3 middlebox compatibility mode (#3595)

From: ekr <[email-masked]>
Date: Fri, 08 May 2020 13:20:30 -0700

@ekr approved this pull request.

> @@ -213,6 +209,11 @@ own key update mechanism {{key-update}}.
 ~~~
 {: #tls-full title="TLS Handshake with 0-RTT"}
 
+{{tls-full}} omits the EndOfEarlyData message, which is not used in QUIC; see
+{{remove-eoed}}. Likewise, neither ChangeCipherSpec nor KeyUpdate messages are
+used by QUIC. ChangeCipherSpec is redundant in TLS 1.3; see {{compat-mode}}.
+QUIC has its own key update mechanism; see {{key-update}}.

Worth noting that it's not possible to send CCS anywya?

> @@ -1631,6 +1632,21 @@ PROTOCOL_VIOLATION.
 As a result, EndOfEarlyData does not appear in the TLS handshake transcript.

+## Prohibit TLS Middlebox Compatibility Mode {#compat-mode}
+
+Appendix D.4 of {{!TLS13}} describes an alteration to the TLS 1.3 handshake as
+a workaround for bugs in some middleboxes. The TLS 1.3 middlebox compatibility
+mode involves setting the legacy_session_id field to a 32-byte value in the
+ClientHello and ServerHello, then sending a change_cipher_spec record. Both
+field and record carry no semantic content and are ignored.
+
+This mode has no use in QUIC as it only applies to middleboxes that interfere
+with TLS over TCP. A client MUST NOT request the use of the TLS 1.3
+compatibility mode. A server SHOULD treat the receipt of a TLS ClientHello that
+requests the use of the TLS 1.3 middlebox compatibility mode as a connection

```suggestion
with a non-empty legacy_session_id field as a connection
```

> @@ -1631,6 +1632,21 @@ PROTOCOL_VIOLATION.
 As a result, EndOfEarlyData does not appear in the TLS handshake transcript.

+## Prohibit TLS Middlebox Compatibility Mode {#compat-mode}
+
+Appendix D.4 of {{!TLS13}} describes an alteration to the TLS 1.3 handshake as
+a workaround for bugs in some middleboxes. The TLS 1.3 middlebox compatibility
+mode involves setting the legacy_session_id field to a 32-byte value in the
+ClientHello and ServerHello, then sending a change_cipher_spec record. Both
+field and record carry no semantic content and are ignored.
+
+This mode has no use in QUIC as it only applies to middleboxes that interfere
+with TLS over TCP. A client MUST NOT request the use of the TLS 1.3
+compatibility mode. A server SHOULD treat the receipt of a TLS ClientHello that
+requests the use of the TLS 1.3 middlebox compatibility mode as a connection

This way you don't need to dig into D.4 to see what the signal is.

-- 
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/3595#pullrequestreview-408499704

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 May 2020 16:24:41 -0700

@martinthomson commented on this pull request.

 ~~~

Not here, but I'll do that below.

-- 
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/3595#discussion_r422715739

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 May 2020 16:25:51 -0700

@martinthomson pushed 1 commit.

3a633d8b22eb2a850b4fed0d7a1e339186885830  reference legacy_session_id directly

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3595/files/cf939cc1e1dd4c40e46856fb335c8208c4a23b5e..3a633d8b22eb2a850b4fed0d7a1e339186885830

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 May 2020 16:27:17 -0700

6a4c95ef0487b3dcfa012330590c6fb1e168c670  You can't carry CCS anyway

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3595/files/3a633d8b22eb2a850b4fed0d7a1e339186885830..6a4c95ef0487b3dcfa012330590c6fb1e168c670

---

From: Christian Huitema <[email-masked]>
Date: Tue, 12 May 2020 10:42:54 -0700

I observe that implementation of this PR is causing interop failures during tests. Some implementations have been updated, some have not been. I recently updated Picoquic to use the latest version of Picotls, and the results are mixed: Handshake with Quant and Quickly that were failing before the update are now succeeding; handshakes with Quiche that were succeeding are now failing. This is clearly a case of spec confusion, with some stacks rushing to test this PR and some sticking to the stated spec. How about clearing that confusion, updating the spec and releasing draft-28?

-- 
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/3595#issuecomment-627491836

---

From: ianswett <[email-masked]>
Date: Tue, 12 May 2020 10:49:25 -0700

@huitema that is the plan as soon as the chairs declare consensus.

-- 
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/3595#issuecomment-627495179

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 12 May 2020 15:22:45 -0700

Yep. The consensus call for this ends tomorrow and there seems to be no push back so far...

-- 
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/3595#issuecomment-627630283

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 May 2020 00:35:26 -0700

Merged #3595 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/3595#event-3335244072