Subject: [quicwg/base-drafts] Get rid of DoS vulnerability in Reserved Bits (#2280)

From: martinduke <[email-masked]>
Date: Sun, 30 Dec 2018 22:07:20 -0800

As currently written, any garbage packet, after removing header protection, will have nonzero reserved bits and bring the connection down. Not good!

Similarly, it is perverse to force me to actually decrypt the full packet to see if it turns out to be a misbehaving end host and comply with the other possible reading of this requirement. Let the receiver just drop the bad packet after header decryption and carry on.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Get rid of DoS vulnerability in Reserved Bits

-- File Changes --

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

-- Patch Links --

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

---

From: martinduke <[email-masked]>
Date: Sun, 30 Dec 2018 22:08:05 -0800

@martinduke pushed 1 commit.

4ae95269177232b01918af4ccc7b006b63cdb3d5  whitespace

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2280/files/4226540cb935df4c65787e48b325e140e44ad710..4ae95269177232b01918af4ccc7b006b63cdb3d5

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Dec 2018 22:41:29 -0800

This requirement exists because if you only remove header protection then throw the packet away, you create a side channel that allows an attacker some leverage on your header protection keys.  [The TLS draft](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.9.3) says:

>  For authentication to be free from side-channels, the entire process of header protection removal, packet number recovery, and packet protection removal MUST be applied together without timing and other side-channels.

Yes, it's perverse, but there are lots of cases where extra work is done to avoid creating side channels.  This ain't static RSA and the attack here isn't a Bleichenbacker attack, but there are good reasons.  And if you are suggesting that this sort of timing can't be observed, that's proven not to be the case before (see [NetSpectre](https://misc0110.net/web/files/netspectre.pdf)).

As for a DoS vulnerability, there are two bits, so you will be doing the work for 1 in four packets anyway.  And it's not hard to find packets with valid sequences.

-- 
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/2280#issuecomment-450613338

---

From: martinduke <[email-masked]>
Date: Sun, 30 Dec 2018 22:50:01 -0800

Ah, so the intent was to apply it after full packet decryption is complete. I'll change the PR to clarify this.

-- 
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/2280#issuecomment-450613779

---

From: martinduke <[email-masked]>
Date: Sun, 30 Dec 2018 22:54:30 -0800

f668691287e3eccf8e330761fdb79f44e4d4edb8  Addressed MT's issue

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2280/files/4ae95269177232b01918af4ccc7b006b63cdb3d5..f668691287e3eccf8e330761fdb79f44e4d4edb8

---

From: Marten Seemann <[email-masked]>
Date: Sun, 30 Dec 2018 22:59:21 -0800

marten-seemann commented on this pull request.

> @@ -3402,9 +3402,10 @@ Reserved Bits (R):
 
 : The next two bits (those with a mask of 0x0c) of byte 0 are reserved.  These
   bits are protected using header protection (see Section 5.4 of {{QUIC-TLS}}).
-  The value included prior to protection MUST be set to 0.  An endpoint MUST
-  treat receipt of a packet that has a non-zero value for these bits after
-  removing protection as a connection error of type PROTOCOL_VIOLATION.
+  The value included prior to protection MUST be set to 0.  An endpoint MUST treat
+  receipt of a packet that has a non-zero value for these bits after removing
+  packet (not just header) protection as a connection error of type

I don't think this is very clear to read. Do we really need to say anything, given that the timing side channel is described in detail in the TLS document?

-- 
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/2280#pullrequestreview-188465206

---

From: martinduke <[email-masked]>
Date: Sun, 30 Dec 2018 23:07:22 -0800

martinduke commented on this pull request.

Oof. I didn't recall that section of the TLS draft. Thanks for pointing that out.

There are a couple of dangers here:
1) The implementer will not check "security considerations" in the tls draft when implementing first byte validation in the transport draft.
2) Naively, the implementation will choose to discard the packet and abort the connection after removing header protection, which opens up a DoS vector, even if goes through the motions of decrypting the packet anyway.

This is coming down to an editorial matter, and I agree my sentence is somewhat clunky. I'm open to other wording, but I don't think the current draft is satisfactory.

-- 
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/2280#discussion_r244558351

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Dec 2018 23:53:13 -0800

martinthomson commented on this pull request.

Let's start with an issue then, shall we?

-- 
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/2280#discussion_r244560666

---

From: martinduke <[email-masked]>
Date: Mon, 31 Dec 2018 00:14:26 -0800

Aren't we down to wordsmithing at this point?

-- 
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/2280#discussion_r244561670