Re: Read-out on offline connection ID discussion

["Brian Trammell (IETF)" <[e-mail]>]

> On 24 Jan 2018, at 23:36, 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.

This seems like a perfectly reasonable starting point.

> - 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.

A question about the details here:

We put the CID (if present) up front in the short header so that it's easy for load balancers to find; the packet number in -08 (which is necessary to sequence and decrypt packets) is similarly easy for the endpoint to find -- CID is fixed length and either present or not.

If the CID is varlen and its length is implicit in the CID itself, then the receiver needs to decode the CID in order to find the offset to the packet number so that it can decrypt the packet number in order to sequence the packet and decrypt the rest of it. This implies the receiver always needs to know how to decode enough of the CID to skip it (which can be trivially done in a transport parameter, but still).

I presume the encrypted representation of the packet number on the wire will be fixed-length, so we can fix this by moving the CID back behind the packet number, but I'm not sure where we are in the tradeoff space between forcing load balancers to skip N bytes before making a routing decision and forcing packet receivers on both sides to always do more work to parse the packet.

Cheers,

Brian


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