Subject: [quicwg/base-drafts] Authenticate Retry (#1710)

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Aug 2018 22:18:07 -0700

The multiple steps involved in Retry are fragile (see #1709), and they are not authenticated.  That is a source of some concern.  As has been observed, an on-the-side attacker gets one shot at rewriting the connection ID as a result of this.  We decided that this isn't a big deal, but the interaction between an attacker-chosen connection ID with packet number encryption is a minor concern.  Maybe it's time to just button this all down fully.

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

---

From: Nick Banks <[email-masked]>
Date: Tue, 28 Aug 2018 06:58:08 -0700

My primary goal with first suggesting the general design we have today with Retry was to support an **independent** DoS mitigation device to be put in path in front of the server. This is a requirement we get from Azure. If any changes to the Retry design require some state to be shared between the mitigation device (we own) and the backend QUIC server (we don't own), that will severely hamper the Azure efforts. It would require some deployment story and would make things a lot more complex for users and would likely go unused then.

You state above that unauthenticated Retry packets are a source of some concern, show that the initial CID can be modified and then go on to say it isn't a big deal (which I agree with). I'm still not really sure what folks are worried about this this supposed attack vector. Initial CID and Initial packet encryption are essentially just used for version ossification prevention. If the attacker understands the version, it's essentially cleartext.

-- 
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/1710#issuecomment-416593915

---

From: MikkelFJ <[email-masked]>
Date: Tue, 28 Aug 2018 07:08:37 -0700

So we don't we add a nonce in the initial packet and pass it along through relevant stages of the handshake and validate it before commiting to a handshake? The nonce replaces the initial connection ID which doesn't really make any sense anyway.

-- 
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/1710#issuecomment-416597537

---

From: Marten Seemann <[email-masked]>
Date: Tue, 28 Aug 2018 09:28:52 -0700

> My primary goal with first suggesting the general design we have today with Retry was to support an independent DoS mitigation device to be put in path in front of the server.

An "**independent** DoS mitigation device" is fundamentally indistinguishable from a middlebox. In all other parts of the protocol we're very careful to design things such that middleboxes can't interfere with the protocol, while at the same time inviting them to do exactly this when it comes to Retries.

I'm still not convinced that this is a reasonable deployment for QUIC. QUIC Initials and TCP SYNs are not really comparable, since we have the 1200 byte requirement for QUIC packets, which will make SYN flood-like attacks orders of magnitude more expensive.

-- 
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/1710#issuecomment-416652335

---

From: Mike Bishop <[email-masked]>
Date: Tue, 28 Aug 2018 10:20:17 -0700

"[A]ll other parts of the protocol" is after the handshake.  We've acknowledged from the beginning that a middlebox can meddle in the handshake; in a few cases, we've taken steps to detect such meddling and abort the connection, but that's not the norm.

I certainly wouldn't object to adding a mechanism that allows the server to detect such a middlebox and kill the connection if it's unexpected.  While I agree that being able to do this without close coordination (shared keys, for example) is valuable, I don't think it's an unreasonable level of coordination to say "I expect such a box" / "I don't expect such a box".

Even a transport parameter that indicates how many Retry packets have been seen prior to the one it's responding to would suffice.  However, that does require the client to (partially or fully) regenerate the 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/issues/1710#issuecomment-416669778

---

From: hardie <[email-masked]>
Date: Tue, 28 Aug 2018 18:32:25 +0000 (UTC)

If a server varies the opaque Retry token for each attempt at a retry, it can already detect which ones of the tokens caused the response and count the number generated.  That also allows it know if there is a gap, without a new transport parameter.  If that's the expected behavior, a client seeing a replayed Retry token would close the connection and a server seeing a token it did not generate would close the connection.   

Presuming that the token is passed with integrity protection at some point, is that enough?

-- 
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/1710#issuecomment-416693688

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Aug 2018 18:30:08 -0700

Here I was thinking of enabling what Mike suggested.  Perhaps the client can copy the Retry (or Retries, or a hash thereof) into its transport parameters and the server can either check at its discretion.

@hardie, there are two pieces that are relevant here: the connection ID and the token.  Both would need some form of checking/protection that is covered by something more strongly authenticated than the Initial keys.  Using Handshake keys would probably work if we needed that, but it's probably easier all around to put something into the cryptographic handshake transcript.  One thing I'm concerned about is the erasure scenario that @kazuho described where a MitM can force a Retry without the server ever being aware of it having happened.

-- 
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/1710#issuecomment-416793025