RE: A better way to do conn id?

[Hannes Tschofenig <[e-mail]>]

Hi Martin,

Your entire story is built on the claim that “variable length conn ids will introduce more complexity in parsers”.

Having implemented parsing of variable length fields in TLS 1.3 extensively last year I have to say that it is not such a big deal, particularly compared to all the complexity found elsewhere (which is also true for QUIC).

In essence you are talking about a few lines of code. Your solution then also requires additional lines of code elsewhere.

Ciao
Hannes

From: QUIC [mailto:[e-mail]] On Behalf Of Martin Duke
Sent: 23 January 2018 23:09
To: IETF QUIC WG
Subject: A better way to do conn id?

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


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.