Subject: [quicwg/base-drafts] Actions to take when Reserved Bits are not Zero (#2329)

From: martinduke <[email-masked]>
Date: Thu, 10 Jan 2019 16:19:57 +0000 (UTC)

A few weeks ago I filed PR #2280 to clarify things a bit. The discussion suggests there is not much consensus. There are three possible equilibria for how to handle nonzero reserved bits:

1) The spec currently says it's a PROTOCOL_VIOLATION. This must occur only after packer protection is removed; after only header protection, 3 out of 4 garbage packets would meet the condition to take down the connection.
2) Alternatively, we could discard the packet after header protection. This is computationally cheaper. There is some concern about consistent decryption time, but as @marten-seemann pointed out if we simply discard there is no response for the attacker to measure.
3) The other choice is to allow senders to do anything with these bits, but that possibility was decisively rejected in #2022 and we shouldn't reopen settled issues in the absence of new information.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Jan 2019 13:14:35 -0800

Thanks for opening the issue.  One point about the second and third options.

> if we simply discard there is no response for the attacker to measure

This is only true if there is no adjacent activity.  I would advise not taking timing side-channels so lightly.

> that possibility was decisively rejected in #2022 

That discussion was mostly about leaving the bits unprotected.  That said, the option of ignoring the bits is potentially valid, but it could give an attacker some leverage on the header protection key.  It wouldn't be much, but it was what pushed me toward the current 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/2329#issuecomment-453256192

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 10 Jan 2019 21:29:07 +0000 (UTC)

Testing the bits prior to AEAD-decryption (option 2) is a no-go. While I am not sure if doing that exposes any information (because there is _no_ information carried by the reserved bits), I prefer having a consistent rule on when the results of header (un)protection can be used.

I think that the choice should be either status-quo or require the receiver to ignore the bits, with the slight preference towards the former.

Honestly, I do not see what we get by requiring the receiver to ignore the bits, because they should not be used in any way without negotiation, to avoid endpoints applying different meanings to the bits.

-- 
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/2329#issuecomment-453260777

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Jan 2019 04:57:31 -0800

What is actually wrong with MUST be set to zero 0 sending and MUST be ignored by receiver. Use of a reserved field normally occur only after negotiation of such use. The exception to the later are if we actually like to use a reserved bit in the parts that are prior to negotiation can occur. 

-- 
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/2329#issuecomment-453995906

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Jan 2019 18:32:54 -0800

Closed #2329.

-- 
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/2329#event-2105382671

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Jan 2019 18:32:56 -0800

Tokyo conclusion: everything is fine.  Thanks for raising the issue.  @martinduke will open/fix an editorial PR on this.

Principle for future stuff agreed:

Protocol violations, when detected, MUST result in a connection error.  Where detecting the error is trivially feasible, then we will require that the endpoint check for the error.

-- 
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/2329#issuecomment-458788361