Subject: [quicwg/base-drafts] Short header reserved bits: make available for unilateral experimentation (#2022)

From: Igor Lubashev <[email-masked]>
Date: Mon, 19 Nov 2018 18:02:52 -0800

(Moving a discussion about this issue from https://github.com/quicwg/base-drafts/pull/2006#discussion_r234690190)

Presently, the two Reserved bits in the short header must be 0 (after removing header protection), unless both client and server agree to use them for a specific purpose.  Unilateral experimentation by the sender using these bits is intentionally disallowed.

The suggestion is to allow these reserved bits to be set at will by the sender and be AEAD protected but not masked during header protection -- just like the latency spin bit. If not in-use for a specific purpose by the sender, the bits should be randomized for greasing.

This way, the sender can use these bits in unilateral experiments (VEC, Loss bit, etc), and the middleboxes will be able to observe but not modify the bits.

There is concern that some experiment may inadvertently compromise connection privacy. Senders should be careful not to leak private information in anything they send, including IP ID fields / IPv6 Flow Labels, TTL/HopLimit fields, DS/ECN fields, packet size choices, packet timings, congestion avoidance behaviors, as well we these two Reserved short header 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/2022

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Nov 2018 18:07:01 -0800

The position I take - and others have commented similarly - is that mutual agreement is the standard we should be holding to here.  The only unilateral feature we have is the spin bit, and that was subject to extensive debate and analysis.

-- 
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/2022#issuecomment-440110341

---

From: MikkelFJ <[email-masked]>
Date: Mon, 19 Nov 2018 18:12:04 -0800

I don't advocate for this, but if it happens, the random greasing should just be the header protection mask, otherwise it gets expensive and additional PRNG as was pointed out earlier in the discussion.

I'd rather see text where the bits are are zeroed and masked by default, but endpoints can negotiate masked or unmasked use via extensions. (Or masked only if people are concerned with ossification).

-- 
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/2022#issuecomment-440111320

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 19 Nov 2018 18:12:31 -0800

What @martinthomson says.

In addition to that, there is a negative performance impact in requiring the implementations not using the bits to randomize them. The requirement to invoke CSPRNG for every packet generation is IMO a bad idea (note: using a non-cryptographically-secure PRNG for the purpose would be an easy way to leak PN).

-- 
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/2022#issuecomment-440111407

---

From: Christian Huitema <[email-masked]>
Date: Mon, 19 Nov 2018 18:12:50 -0800

I agree with @martinthomson. We had extensive studies for the privacy effect and efficiency of the spin bit. We also have studies showing that the VEC extensions were not necessary. There may well be a case for some error measurement extension, but it should be studied in details before any large deployment. And for experimental deployment, bilateral agreement is probably fine. I could argue that it is in fact required if clients and servers are to agree to experiment with a specific error detection algorithm.

-- 
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/2022#issuecomment-440111499

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Nov 2018 18:13:25 -0800

> the random greasing should just be the header protection mask

This isn't possible - the value of the mask can be dependent on the value of these 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/2022#issuecomment-440111594

---

From: ianswett <[email-masked]>
Date: Mon, 19 Nov 2018 18:15:40 -0800

I agree with @martinthomson and the corresponding WG consensus.

That doesn't prevent new experimentation when both sides participate, however.  And I think that's the most important feature to preserve.

-- 
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/2022#issuecomment-440112026

---

From: Marten Seemann <[email-masked]>
Date: Mon, 19 Nov 2018 18:17:46 -0800

As I said in https://github.com/quicwg/base-drafts/pull/2006#discussion_r234758007:

I see that as a feature, rather than a bug. We’re making it harder for one endpoint to expose potentially privacy sensitive information to third parties, if its peer isn’t consenting. Of course, we can never fully prevent that, but at least we can make it harder and increase the overhead for that.

-- 
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/2022#issuecomment-440112407

---

From: MikkelFJ <[email-masked]>
Date: Mon, 19 Nov 2018 18:24:02 -0800

> This isn't possible - the value of the mask can be dependent on the value of these bits.
The PN is after these bits no? You just set the bits first, apply packet protection, then the mask?
The first byte is never sampled by header protection unless sample length is longer than the AEAD tag - which of course is still not fully nailed.

-- 
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/2022#issuecomment-440113666

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Nov 2018 18:32:38 -0800

@mikkelfj, I don't think that we're talking about the same thing, but it doesn't matter all that much.

-- 
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/2022#issuecomment-440115299

---

From: Mike Bishop <[email-masked]>
Date: Tue, 20 Nov 2018 11:33:31 -0800

I think I see the issue, though we're skirting the outer edges of my crypto here, so I'd like to confirm.  The cheap way to deal with this would *seem* to be taking those two extra masking bits from the packet number protection and using them to mask off the bits iff you're not using them.  But that doesn't work, because you don't have the PNP mask until after you've committed to a value.

The pre-masking value (currently required to be 0) is in the AAD, which influences the output of the AEAD tag (and the ciphertext?).  The sampled input for packet number protection can come from the AEAD tag, so anything that modifies the AAD potentially modifies the PNP mask.

To validate, the recipient would need to generate the PNP mask, then check the packet against the authentication tag for both the bits-as-received and the bits-as-would-have-been-masked, then accept the packet if either were valid.  (Since we're talking about two bits, there's also a ~33% chance that if someone on the network decided to fiddle those bits, the recipient would decide it was still okay.)

In order to avoid trial decryption and undetected meddling, the recipient has to know whether to unmask those bits before validating the packet or not.  Either we declare them unmasked and random-if-not-used, which entails an extra CSPRNG call for those two bits in the non-experiment case; or we declare them masked unless the peers negotiate otherwise.  (The value pre-masking doesn't actually matter, but since the network can't observe it, it's useless for these experiments.)

Did I get all that?

-- 
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/2022#issuecomment-440402331

---

From: MikkelFJ <[email-masked]>
Date: Tue, 20 Nov 2018 11:37:39 -0800

>  But that doesn't work, because you don't have the PNP mask until after you've committed to a value.

I don't think that is true. I can't see why you would only know the contents of the bits until after you have applied AEAD packet protection? That is, unless you want to expose the bits publicly in which case you just don't apply the mask. Both endpoints would already agree on whether the mask applies to these 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/2022#issuecomment-440403651

---

From: Mike Bishop <[email-masked]>
Date: Tue, 20 Nov 2018 19:42:46 +0000 (UTC)

The packet header is input to the AEAD for packet protection, the output of which is input to the packet number protection.  So the PNP mask potentially depends on every bit of the pre-protection header, unless I'm misunderstanding something.

-- 
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/2022#issuecomment-440405223

---

From: MikkelFJ <[email-masked]>
Date: Tue, 20 Nov 2018 19:58:17 +0000 (UTC)

I could be wrong. But the receiver first unmasks the header protection, then removes packet protection. The sender first generates all bits in the packet, including all header bits, then applies packet protection. The applies the header protection mask with an XOR.

The current text says the bits are 0. This works. Saying the bits are something else would work equally well.

What will not work is being in doubt about which bits the header protection mask applies to. Some extension could negotiate away the mask on the first CID change or something.

-- 
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/2022#issuecomment-440409826

---

From: MikkelFJ <[email-masked]>
Date: Tue, 20 Nov 2018 12:17:26 -0800

However, it is bad to have a negotiable mask size. The header protection should be able to work in a hardware offload environment, or parallel process, that does not know the current connection state, at least beyond version number.

-- 
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/2022#issuecomment-440415377

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 20 Nov 2018 18:09:35 -0800

@mikkelfj 
> However, it is bad to have a negotiable mask size. The header protection should be able to work in a hardware offload environment, or parallel process, that does not know the current connection sta…

I disagree that having a negotiable mask size is a bad thing.

If you are to build a hardware offloader, you should create it so that different encryption algorithms can be applied for different CIDs.

For example, as you state, the algorithm would be different between different two CIDs if the protocol versions are different between the two. Having a different mask based on negotiation is not at all different (note that you would can install the 1-RTT key and the mask to the offloader at the same moment).

-- 
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/2022#issuecomment-440502306

---

From: MikkelFJ <[email-masked]>
Date: Tue, 20 Nov 2018 23:40:42 -0800

I tend to agree, some coordination is unavoidable - e.g. inform about CID/key rslations.

-- 
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/2022#issuecomment-440566785

---

From: Igor Lubashev <[email-masked]>
Date: Wed, 21 Nov 2018 22:20:26 -0800

@MikeBishop, if I understand it correctly, you are trying to solve a problem of how to pick two random random bits for greasing, if the sender is not using those bits for anything. I would argue that it is a relatively simple obstacle.

The real obstacle to a sender unilaterally using the two unused bits is _not_ technical.  The problem is WG's desire to prevent implementation of anything observable by the path for the fear that the sender will misuse the bits and accidentally reveal something that the receiver would object to.  I am a bit at awe at this position -- this is beyond the fear of a third-party middlebox vendor; this is a mistrust in the actual party to the connection.  Yet, the majority of the WG seems to strongly support just that position, so we may decide to declare it a consensus position.  In any case, I am glad this got discussed and seems to be getting settled.

-- 
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/2022#issuecomment-440924853

---

From: janaiyengar <[email-masked]>
Date: Mon, 26 Nov 2018 19:14:03 -0800

@igorlord : I don't think this is mistrust in the endpoint.  Negotiation of this feature means that both endpoints agree to a certain level of privacy from middleboxes, and one might argue that unilateral use means that the end with the weakest level of privacy always wins.

As you note, there seems to be clear support to disallow unilateral use. I'm closing this issue; please reopen if anyone thinks further discussion is warranted.

-- 
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/2022#issuecomment-441884478

---

From: janaiyengar <[email-masked]>
Date: Tue, 27 Nov 2018 03:14:04 +0000 (UTC)

Closed #2022.

-- 
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/2022#event-1988453944