Re: Greasing the QUIC Bit

[Christian Huitema <[e-mail]>]

I am almost done implementing this in picoquic, I just have a question
about to set the quic bit if the option is negotiated

The spec says "use an unpredictable value", and I am hesitating between
three options:

1) flip a coin upon negotiation of the TP, and set all Quic Bits for the
connection to the selected value.

2) flip the bit at every packet.

3) run a random number generator for each packet.

The problem is that it has to be both unpredictable and testable.
Testable would mean "run a test connection, and check that the Quic bit
is zero some of the time". This kind of rules out the "one coin per
connection" option, because then some connections will never set the bit
to zero. Flip on every packet is testable, but is hardly unpredictable.
The RNG is a statistical test. It can still statistically fail, unless I
run the test for long connections. Also, it is hard to make it
repetitive. I will probably end up with some RNG variant, but this does
not make me too happy...

-- Christian Huitema

On 7/2/2020 5:41 PM, Martin Thomson wrote:
> Multi-reply, inline...
>
> On Thu, Jul 2, 2020, at 22:57, Stephane Bortzmeyer wrote:
>> Isn't it the point of draft-ietf-quic-invariants? If it is not an
>> invariant, it may change.
> Indeed it is the point of that document, and we do not promise that the value is constant.  But actions are louder than words and QUIC version 1 fixes the bit, so there is the concern that the words in -invariants won't have an effect.
>
>
> On Thu, Jul 2, 2020, at 23:18, Brian Trammell (IETF) wrote:
>> I continue to fear that the demand for on-path discrimination of QUIC 
>> traffic will remain [...]
> Ack.  The question for me is how much this bit was ever likely to sufficient for that purpose.
>
>
> On Fri, Jul 3, 2020, at 06:20, Dmitri Tikhonov wrote:
>> Why don't you pick a TP number -- let's interop on it during the
>> upcoming Interop.
> As the rules for the registries allow, the draft has a number in it.  I'll see about implementation.  It shouldn't take too long :)
>
>
> On Fri, Jul 3, 2020, at 06:38, Mike Bishop wrote:
>> Seems like the most straightforward way to grease it to be extending 
>> header protection to cover that bit as well.  It's always set to 1, but 
>> you change the mask you're using on the first byte of header protection 
>> and get instant variability, just like the reserved bits.  I'm 
>> surprised the document doesn't mention that way of implementing it, 
>> even if it's hardly the only way to achieve an "unpredictable value."
> This remains the most difficult question for me.  I spent a good amount of time thinking about this and never really reached a conclusion I was happy with.
>
> The use of the masking to generate an unpredictable value might sound good, but it isn't good.  Unless you can meet some very particular constraints - and you disassemble your AEAD - the value of the mask depends on the value of the bit, so you can't use masking bits to decide the value.  You might save bits from the last packet for the next one, I guess, but that's just an RNG.
>
> It's this that makes the question of masking difficult.
>
> If you mask the bit, then you need to be sure that recipients know when it is masked.  That means you can't apply the new rule for generating the bit prior to negotiating the extension.  In practice, that means you can only realistically affect 1-RTT packets (and maybe 0-RTT packets).
>
> If you don't mask the bit, then you can toggle the value of bit any time you think your peer might be OK with it, including for new connections.  The value you send is what is authenticated.  But that prevents you from masking the value of the bit.  Or at least it makes it much more difficult to use the bit to carry a value for which you require end-to-end confidentiality.  I can think of a couple of tricks, but they require some crypto-juju to avoid some fairly nasty costs.
>
> In the end, not masking is easier to specify and implement, so that was the decider :)  The effect is that this is better suited to path signals than end-to-end signals.
>