Re: Read-out on offline connection ID discussion

[Mikkel Fahnøe Jørgensen <[e-mail]>]

I don’t understand this requirement for the CID to be 16 bytes in order to
be encrypted.
If you have a unique key you can encrypt 0, truncate and xor with the CID.
If you don’t have a unique key, you can encrypt a unique counter value and
do the same, or derive a unique key.


Kind Regards,
Mikkel Fahnøe Jørgensen


On 24 January 2018 at 23.37.30, Eric Rescorla ([e-mail]) wrote:

Hi folks,

We didn't really reach a conclusion, but here's, I think what there
was at least some support for:

- The long header has a variable length connection ID which has an
  explicit length field on the wire, with a max length (strawman: 32
  bytes). The exact wire encoding to be designed by the editor.
  Similarly, NEW_CONNECTION_ID would have a variable length
  encoding.

- The short header has a variable length connection ID which has
  an implicit length (i.e., it cannot be decoded unambiguously
  by an observer who is not part of the connection). However,
  the CID may be self-describing, so that the server may include
  a length field if it so chooses.

There was rough consensus on the second point, but some disagreement
about the first point. The major alternative proposal was to have
a fixed-length CID field in the long header and NEW_CONNECTION_ID
and then truncate it to an amount carried in transport_parameters.
This would have the benefit that the length of the CID would be
throughout the connection whereas if we wanted that rule for the
other design we would need a rule.

One thing that makes this second approach unattractive is that we want
the server to be able to use a 16 byte connection ID (thus allowing it
to be AES-encrypted) but it also needs to be able to include
meta-data, such as a key-id for rotation or potentially a length. This
tells us that you need to have a maximum connection ID larger than 16
bytes, and having a fixed 17-20 byte CID seems odd.

-Ekr