Re: The first octet

[Christian Huitema <[e-mail]>]

On 8/5/2018 10:55 PM, Martin Thomson wrote:

> Process
>
> Given that we don't have answers to some questions we might conclude
> several ways.  I proposed that we agree on principles, starting with:
>
> 0. (This should already be agreed, but I'm repeating it because it's
> important.)  The low 7 bits of the first octet are version-specific
> and can change in the next version of the protocol.
Yes.
> A. What do we want to do with unused bits?  Do we want to ensure that
> they are always used?  Or can they be reserved?  If so, how would they
> be reserved (fixed values, random values, greasing, etc...)?

My fast-brain response would be to use random values, 0b1RRRRRxx, and do
T=octet|0b01111100 when decoding the long header. But that's probably
wrong, because of side channels, etc. The next alternative is to define
several QUIC versions, with different codes for the four long header
types. That would grease both the types and the version field, and would
probably be a better way to teach middle-boxes not to make assumptions.

> B. Should things in the first octet be encrypted where possible (for
> example, using an extension of packet number encoding).

That's tempting, but the decryption key is function of the packet type:
epoch 0 for initial, epoch 1 for 0rtt, epoch 2 for handshake, clear text
for retry. Encrypting the packet type means trial decryption. Do we
really want to do that?

>
> C. Should packet number encodings should be consistent between long
> and short header forms?

Took me some time to parse what you wanted to say. I think you mean
something like, "if we move the number length bits to first octet of the
short header, should we also reserve the same two bits to encode the
number length bits in the first octet of the long header?" Maybe. Or
just say that packet numbers in the long header are always encoded on 32
bits, which might be even simpler.

-- Christian Huitema