Subject: [quicwg/base-drafts] Avoid failure from spoofed/delayed PATH_RESPONSE (#1263)

From: martinduke <[email-masked]>
Date: Wed, 04 Apr 2018 16:34:39 +0000 (UTC)

Bogus PATH_RESPONSE in a Handshake packet seems like an obvious DoS attack.

Also, I added some language about storing PATH_CHALLENGE data for a really long time if we're going to send an error. I would actually prefer that we get rid of this error code entirely, as it seems like a great way to accidentally tear down connections when the new path's RTT is way higher than expected.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Avoid failure from spoofed/delayed PATH_RESPONSE

-- File Changes --

    M draft-ietf-quic-transport.md (7)

-- Patch Links --

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Apr 2018 19:25:12 -0700

martinthomson commented on this pull request.

> @@ -2784,8 +2784,11 @@ frame.  Its format is identical to the PATH_CHALLENGE frame
 
 If the content of a PATH_RESPONSE frame does not match the content of a
 PATH_CHALLENGE frame previously sent by the endpoint, the endpoint MAY generate
-a connection error of type UNSOLICITED_PATH_RESPONSE.
-
+a connection error of type UNSOLICITED_PATH_RESPONSE. Endpoints MUST NOT
+generate this error in response to a PATH_RESPONSE frame in a Handshake Packet.

I don't think that we need to worry about this.  We have agreed not to specifically defend against tampering with the handshake.  Note that you need to be on-path for this to work, because of the handshake packet protection design.

> @@ -2784,8 +2784,11 @@ frame.  Its format is identical to the PATH_CHALLENGE frame
 
 If the content of a PATH_RESPONSE frame does not match the content of a
 PATH_CHALLENGE frame previously sent by the endpoint, the endpoint MAY generate
-a connection error of type UNSOLICITED_PATH_RESPONSE.
-
+a connection error of type UNSOLICITED_PATH_RESPONSE. Endpoints MUST NOT
+generate this error in response to a PATH_RESPONSE frame in a Handshake Packet.
+Endpoints SHOULD NOT generate this error if they are not storing the
+PATH_CHALLENGE data well in excess of any plausible packet round-trip time on
+a new path, as a late response would result in connection teardown.

I don't think that we need to say this either, because if the endpoint isn't sure that it sent the challenge, then permission to end the connection isn't implied.

-- 
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/1263#pullrequestreview-111861766

---

From: Mike Bishop <[email-masked]>
Date: Fri, 13 Apr 2018 21:31:28 +0000 (UTC)

#1265 would subsume this, if it goes to the extent Patrick wants.  And perhaps this PR should address that issue.  But assuming we're not actually removing the error entirely....

Just because we've agreed we're not going to go out of our way to make the handshake tamper-proof, that doesn't mean we have to ignore low-hanging fruit.  This is goodness, and the cost is effectively zero.

-- 
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/1263#issuecomment-381265682

---

From: martinduke <[email-masked]>
Date: Sat, 14 Apr 2018 04:24:42 +0000 (UTC)

@martinthomson makes some good points about the handshake. Has anyone done an audit of possible on-path and off-path attacks on the handshake? If a bogus PATH_RESPONSE is neither cheaper nor more effective than other handshake attacks, then I agree there's no point in worrying about it.

As for the discarded challenge issue, by definition a "should" isn't something we need to say. I'll leave it to the editors as to whether it's worthwhile or not.

-- 
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/1263#issuecomment-381302344

---

From: ianswett <[email-masked]>
Date: Sun, 15 Apr 2018 11:06:54 -0700

@bemasc Has spent quite a bit of time thinking about on and off-path attacks on 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/pull/1263#issuecomment-381425809

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Mon, 16 Apr 2018 15:32:00 +0000 (UTC)

> Bogus PATH_RESPONSE in a Handshake packet seems like an obvious DoS attack.

@martinduke Alas, the QUIC handshake is full of such attacks.  The specification generally requires or recommends that clients terminate the handshake if the remote party appears to be misbehaving, and an on-path attacker can easily trigger that termination behavior in many different ways.

I'm very interested in resolving this problem, but I think it's too early be trying to fix this in the QUIC specification, which is still very much in flux.  Once the QUIC protocol is finalized, perhaps we can have a discussion about what it would take to harden 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/pull/1263#issuecomment-381646894

---

From: martinduke <[email-masked]>
Date: Mon, 16 Apr 2018 12:25:28 -0700

Thanks @bemasc. Is there an open issue for this assessment? If so, I am happy to close this PR.

-- 
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/1263#issuecomment-381720188

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Apr 2018 14:19:18 +0000 (UTC)

I will close this for now.  We currently have consensus not to harden the handshake against disruption by an on-path attacker.  I think that there is plenty of interest in looking at hardening the handshake against tampering and disruption, but those efforts aren't currently in scope.  Any attempt to do that will likely need to be marked `quicv2`, as Ben notes.

-- 
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/1263#issuecomment-384303756

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Apr 2018 07:19:19 -0700

Closed #1263.

-- 
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/1263#event-1594197445