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

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Apr 2020 15:27:35 -0700

This came up in interop testing.  This mode causes the TLS stack to generate a ChangeCipherSpec message, which caused our server to crash.  That's a bug on our end, but it's still a problem.

We need to decide whether this mode is acceptable.  Right now, we only say that it is "redundant".  A prohibition this mode would be easier all around.  It would avoid spending 32 bytes for both endpoints too.

Unfortunately, this is a design change.

-- 
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/issues/3594

---

From: David Schinazi <[email-masked]>
Date: Wed, 22 Apr 2020 16:08:31 -0700

I'm not sure what this change would get us. Isn't it simpler to ignore CCS on receipt instead of requiring the receiver to check for CCS and fail 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/issues/3594#issuecomment-618085027

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Apr 2020 16:13:10 -0700

So yes, one answer is to ignore it and move on.  But we should say that and require that implementations do so.

The answer I prefer is prohibition.  This is wasted bytes.

-- 
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/issues/3594#issuecomment-618086281

---

From: David Schinazi <[email-masked]>
Date: Wed, 22 Apr 2020 16:22:12 -0700

If this were purely a QUIC matter, I would agree. This one is slightly trickier because it puts additional requirements on TLS stacks and not all QUIC implementers control their TLS stack. Additionally, is this a principled approach? Should we also be banning TLS padding (RFC7685) because it is similarly redundant?

-- 
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/issues/3594#issuecomment-618089069

---

From: ianswett <[email-masked]>
Date: Wed, 22 Apr 2020 16:49:23 -0700

Practical question: Is there anyone for whom this restriction would be onerous?

Ideally there would be a day we'd be able to get rid of compatibility mode for TLS 1.3 entirely, so prohibiting it from QUIC seems like the first step.  As a corollary, it seems like TLS implementations should have a knob to enable/disable it, otherwise compatibility mode becomes the de-facto only mode.

-- 
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/issues/3594#issuecomment-618096655

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Apr 2020 16:51:18 -0700

Our client has a switch that defaults to off.  Apparently picotls had no switch, but @kazuho already [fixed it](https://github.com/h2o/picotls/pull/305).

-- 
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/issues/3594#issuecomment-618097188

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 22 Apr 2020 20:28:05 -0700

Just to be clear, picotls has had the switch, but it has been sending a 32-byte legacy_session_id even when the switch was off. That was a violation of a MUST in RFC 8446, purely implementation bug.

@DavidSchinazi 
> I'm not sure what this change would get us. Isn't it simpler to ignore CCS on receipt instead of requiring the receiver to check for CCS and fail the handshake?

In QUIC, it is impossible to send CCS, because the CRYPTO streams of QUIC can only carry handshake messages. CSS is not a handshake message, it's a TLS record. Therefore, it is my understanding that this issue is an editorial clarification.

-- 
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/issues/3594#issuecomment-618155197

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Apr 2020 00:55:49 -0700

Just to close the loop (and discuss on the issue): Having a SHOULD on the server reaction is fine with me.

-- 
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/issues/3594#issuecomment-618243235

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Apr 2020 04:50:52 -0700

Sounds like design?

-- 
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/issues/3594#issuecomment-619933402