Re: A better way to do conn id?

[Kazuho Oku <[e-mail]>]

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