RE: A better way to do conn id?

["Lubashev, Igor" <[e-mail]>]

The argument that connection id can be self-describing is not wrong.

Connection id can be self-describing, and it would need to be, if the sever is to allow using different lengths for different connections and to do key rotation. It does add complexity to connection id generation (cannot easily use AES instruction to do encryption) and reduces the number of available bits, even for shorter connection IDs.

Victor's suggestion is to use just one extra bit in the packet type octet to avoid all of these troubles. It does bring up questions of requiring consistency in those bits throughout the connection lifetime - a definite "cost" of the scheme. But it also has benefits (see above). So this seems to be a viable option, but not a obvious option (since trade-offs are needed).

- Igor

-----Original Message-----
From: Subodh Iyengar [[e-mail]]
Received: Wednesday, 24 Jan 2018, 3:00AM
To: Lubashev, Igor [[e-mail]]; Martin Duke [[e-mail]]; Martin Thomson [[e-mail]]
CC: IETF QUIC WG [[e-mail]]
Subject: Re: A better way to do conn id?


> (Victor voiced this today) Steal a code point from the packet type: have 2 bits that represent

Why do we need to represent the size of the connection id as bits in the packet? We usually represent the lengths as bits in the packet for 2 reasons:


  1.  to be able to change them per packet
  2.  If they need to be interpreted by unrelated parties.

I raised this question in the meeting today whether or not connid size needs to change with every packet and the answer seemed no. Also in the current design the interpretation of connid is only relevant to the server / related parties, in which case the server could represent it's connid in its own self describing format which doesn't need any new bits. L3 load balancers and L7 load balancers would share the knowledge of the format of the connection id to determine how long it is. So it would seem like we don't need any extra bits. Are any of these assumptions I'm making incorrect?


Subodh

________________________________
From: QUIC <[e-mail]> on behalf of Lubashev, Igor <[e-mail]>
Sent: Tuesday, January 23, 2018 9:34:47 PM
To: Martin Duke; Martin Thomson
Cc: IETF QUIC WG
Subject: RE: A better way to do conn id?


The two alternatives to allow for key rotation to “avoid” going over 16 octets are:



  1.  (Victor voiced this today) Steal a code point from the packet type: have 2 bits that represent:

0-byte connection id;

8-byte connection id;

16-byte connection id (key a);

16-byte connection id (key b)



  1.  “Trial Encryption” : Steal a bit from your 128 bit connection ID

Your bit 0 of your Connection ID will represent the key used for encryption.
Since you have entropy in your Connection ID, keep generating new entropy and encrypting, until bit 0 comes out just the way you want it.  On average, you will do 0.75 extra encryption operations.



  *   Igor



From: Martin Duke [mailto:[e-mail]]
Sent: Wednesday, January 24, 2018 12:21 AM
To: Martin Thomson <[e-mail]>
Cc: IETF QUIC WG <[e-mail]>
Subject: Re: A better way to do conn id?



Very well, replace 16 with whatever number you guys come up with.



On Wed, Jan 24, 2018 at 4:19 PM, Martin Thomson <[e-mail]<mailto:[e-mail]>> wrote:

We have already concluded that if you want to do sane crypto, plus
some sort of key identification, then you need MORE than 16 octets
(though not much more).  That makes things more complicated.  ekr has
an outcome that he will write up.

On Wed, Jan 24, 2018 at 4:08 PM, Martin Duke <[e-mail]<mailto:[e-mail]>> wrote:
> Today's variable-length connection ID discussion made me realize some
> problems with the current architecture, while the new architecture doesn't
> fix some of them and creates whole new ones. Issues:
>
> - The client desires unlinkability, but I suspect the market will provide no
> incentives for servers to work very hard to be unlinkable. There were
> conflicting "layer 9" arguments that variable conn ID makes this problem
> worse or better.
>
> - 16 Bytes is more overhead than 8 bytes.
>
> - The severity of this remains to be seen, but variable length conn ids will
> introduce more complexity in parsers and anything that utilizes the conn id
> (e.g. handshake key generation). It might make the invariants more complex
> as well. The whole thing, frankly, makes my head hurt.
>
> I humbly suggest the following proposal might avoid or mitigate some of
> these problems:
>
> 1. Every connection has a long-lived Client-generated Connection ID (CGCID)
> and Server-generated Connection ID (SGCID). The CGCID is 8 bytes and the
> SGCID is 16 bytes.
>
> 2. The CGCID is used to derive the handshake key. (unchanged from status
> quo)
>
> 3. The initial packet uses the CGCID.  All other handshake packets use the
> SGCID. This is unchanged from the status quo.
>
> 4. All 1-RTT packets by sent by the client use the SGCID. All 1-RTT packets
> sent by the server use the CGCID. This has two important properties:
>            a) The server gets the 16 Bytes of entropy the load balancer
> needs
>            b) The server->client direction, which in the usual case has most
> of the data, has a lower-overhead CID.
>
> 5. The algorithm that generates SGCID MUST have different output given a
> different CGCID. [We might strengthen this language further: you wouldn't
> want to simply add the NEW_CONN_ID sequence number to the existing SGCID,
> for instance].
>
> 6. In advance of migration, the client sends a NEW_CONN_ID frame to provide
> a new CGCID (possibly omitting the stateless reset token). The server MUST
> respond with a NEW_CONN_ID that provides a new SGCID derived from the new
> CGCID. All packets on the new path use these CIDs.
>
> If people like this, I can generate a PR. I am very open to various tweaks
> to the general approach as well. I wanted to get this out there before the
> variable-length CID team gets deep in the weeds.
>
> Martin Duke
>
>