Subject: [quicwg/base-drafts] Does a Retry really need to change the CID? (#2837)

From: ianswett <[email-masked]>
Date: Mon, 24 Jun 2019 07:01:40 -0700

>From section 17.2.5: https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-17.2.5
"This value MUST not be equal to the Destination Connection ID field of the packet sent by the client."

This was originally added when multiple Retrys were supported.  I don't think it's still necessary, but if it is, I'd like to add some rationale, because it's not obvious to me why this restriction is necessary.

Past slides from Martin: https://github.com/quicwg/wg-materials/blob/master/interim-18-09/retry.pdf

-- 
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/2837

---

From: Marten Seemann <[email-masked]>
Date: Mon, 24 Jun 2019 07:16:07 -0700

If I understand correctly, it's still necessary to prevent a MITM from performing a Retry (and then removing the token from the second Initial).

-- 
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/2837#issuecomment-505029280

---

From: ianswett <[email-masked]>
Date: Mon, 24 Jun 2019 07:34:46 -0700

Fair point.  Is that an 'attack' that we're concerned about?  That sounds like @nibanks ideal DDoS device, actually.

-- 
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/2837#issuecomment-505037200

---

From: Nick Banks <[email-masked]>
Date: Mon, 24 Jun 2019 07:39:11 -0700

Generally, I believe the goal is to prevent all unauthorized tampering with the handshake. If it happens, it should be detected and the handshake fails. I agree with this philosophy even though it does make the Retry scenario a bit trickier to offload.

Also, even if that was allowed, designing a DDoS device around it would be tricky still. You'd have to handle the case where the peer only pads their packet up to 1200 bytes **including the token**, so if you removed it, the backend server wouldn't accept it.

-- 
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/2837#issuecomment-505039122

---

From: ianswett <[email-masked]>
Date: Mon, 24 Jun 2019 07:40:38 -0700

Good point, it seems like we can fix this with an editorial PR to clarify the risk of not changing CID on Retry.

-- 
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/2837#issuecomment-505039758

---

From: David Schinazi <[email-masked]>
Date: Mon, 24 Jun 2019 09:34:40 -0700

@nibanks the retry token is part of the initial encryption associated data, so if you remove it you'll need to recompute the crypto anyway.

@marten-seemann can you elaborate on what the consequences of this attack are? It sounds like the attacker can close the connection by sending a bad retry. How is that different from having the attacker send a bad retry that changes the CID and contains a bogus retry token?

-- 
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/2837#issuecomment-505085436

---

From: ianswett <[email-masked]>
Date: Mon, 24 Jun 2019 09:39:49 -0700

Q: Should the retry token be part of the TLS transcript?  That might prevent a whole class of issues?

-- 
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/2837#issuecomment-505087284

---

From: David Schinazi <[email-masked]>
Date: Mon, 24 Jun 2019 09:45:21 -0700

@ianswett The `original_connection_id` transport parameter ensures that part of the retry token is in the TLS transcript. If the retry token is protected by authenticated encryption (which it should) then transitively we already have tamper protection for the retry token. The issue here is that if the retry token is tampered with, then the connection is closed. But I don't see how changing the server connection ID during retry changes that though (as long as not changing the CID still requires sending the transport parameter).

-- 
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/2837#issuecomment-505089084

---

From: Nick Banks <[email-masked]>
Date: Mon, 24 Jun 2019 09:47:47 -0700

@DavidSchinazi I think one worry was that if a middle box had the ability to change the CID using Retry, then they could more easily attack packet protection. @kazuho could probably add more 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/issues/2837#issuecomment-505089866

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 24 Jun 2019 17:21:46 -0700

@nibanks @DavidSchinazi I think you are referring to #1486 (which is a general statement), with one of the possible attacks being https://github.com/quicwg/base-drafts/issues/1451#issuecomment-398921875.

-- 
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/2837#issuecomment-505228923

---

From: David Schinazi <[email-masked]>
Date: Mon, 24 Jun 2019 17:27:21 -0700

@kazuho I'm not sure I understand the attack, if the middlebox has access to the server's retry token key then it can do bad things, but I don't think that's worth protecting against.

-- 
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/2837#issuecomment-505229917

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 24 Jun 2019 18:00:31 -0700

@DavidSchinazi Yeah I think that the issues being described in the provided links has been fixed by introducing the ODCID TP (and therefore requiring the retry token key to be shared).

-- 
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/2837#issuecomment-505235708

---

From: David Schinazi <[email-masked]>
Date: Tue, 25 Jun 2019 09:52:49 -0700

Thanks @kazuho . Given that, does anyone see a reason to require changing the CID with retry?

-- 
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/2837#issuecomment-505529927

---

From: Mike Bishop <[email-masked]>
Date: Tue, 25 Jun 2019 10:51:01 -0700

Consider the case where:
- Client sends Initial packet 0, no token, DCID A
- Client times out the Initial packet and sends Initial packet 1, no token, DCID A
- Client receives a Retry with ODCID = SCID = A.
- Client sends Initial packet 2, with token from Retry, DCID A
- Client receives a Retry with ODCID = SCID = A.

Is this Retry a response to packet 1 from a stateless server with a high RTT, or a prohibited second Retry in response to packet 2?  If packet 2 carries a different DCID, the client can tell by inspecting the ODCID field in the Retry packet.  If packet 2 uses the same DCID as packets 0-1, it can't tell.

Requiring a change allows the client to determine that the server isn't misbehaving in this case.

-- 
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/2837#issuecomment-505551934

---

From: David Schinazi <[email-masked]>
Date: Tue, 25 Jun 2019 11:19:46 -0700

Thanks @MikeBishop , that makes sense. I'm not 100% sure detecting this class of bad behavior is worth the added requirement on the protocol though.

-- 
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/2837#issuecomment-505562723

---

From: Mike Bishop <[email-masked]>
Date: Tue, 25 Jun 2019 11:22:43 -0700

We had other reasons why this was critical, but we've changed other requirements in the spec that eliminated them.  (For example, when the client was permitted to change the ClientHello following a Retry, you had to know *which* Initial the server wound up responding to or the handshake would fail.)

-- 
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/2837#issuecomment-505563869