RE: A better way to do conn id?

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

Thanks for pointing out the hazard of key rotation frequency vs connection duration.


  *   Do we want to bake such restriction into the protocol?

The extra codepoint proposal is a helpful common-case optimization, in case the frequency of key rotation is sufficiently low.  It is definitely not a solution for all possible use cases.  However, there is nothing to prevent a server with more frequent key rotations to do something else.  The “something else” could be:

  1.  Encode additional bit(s) in the connection ID
  2.  Before expiring key A, create state on the load balancers for the few very long-lasting connections still using A.
  3.  Something else


Your idea of having a mechanism to force a switch to the new connection ID is an interesting and separate idea.  I am in favor of this, as it may give us more flexibility.  Don’t see that this must be a v1 feature.


  *   Igor


From: Kazuho Oku [mailto:[e-mail]]
Sent: Wednesday, January 24, 2018 9:20 AM
To: Lubashev, Igor <[e-mail]>
Cc: Martin Duke <[e-mail]>; Martin Thomson <[e-mail]>; IETF QUIC WG <[e-mail]>
Subject: Re: A better way to do conn id?



2018-01-24 16:34 GMT+11:00 Lubashev, Igor <[e-mail]<mailto:[e-mail]>>:
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.

Thank you for summarizing the two approaches.

What I am bit afraid of using the bits in the packet type is that the approach hardcodes the relation between the frequency of key rotation and the maximum lifetime of a QUIC connection.

Consider the case where you want to switch from key A to key B. Correct me if I am wrong, but IIUC there is no way for a server to enforce the client to switch to a new connection ID. Therefore, the server will be enforced to shutdown all the connections using the IDs generated by using key A before the key gets retired.

For example, if you plan to do the rollover from key A to key B in 24 hours, the minimum maximum of the lifetime of a connection will be restricted to 24 hours.

Do we want to bake such restriction into the protocol?

If we use trial encryption, the issue between the sped of key rotation and the minimum maximum of a QUIC connection would be left to each server-side implementation, though you might end up being required to do more "mining" (i.e., find a connection ID that can survive _multiple_ generations of key rotations).

Or, should we introduce a mechanism that allows a server to _enforce_ connection ID migration, considering the fact that the issue exists in both approaches?




  *   Igor

From: Martin Duke [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, January 24, 2018 12:21 AM
To: Martin Thomson <[e-mail]<mailto:[e-mail]>>
Cc: IETF QUIC WG <[e-mail]<mailto:[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
>
>




--
Kazuho Oku