Subject: [quicwg/base-drafts] Assymetric connection ID (#1089)

From: MikkelFJ <[email-masked]>
Date: Wed, 31 Jan 2018 13:37:38 -0800

This is probably a v2 thing

The multiple connections per tuple has been shot down for v1, but let's consider the general case:

Two hosts in one or more data centers establish peer to peer communication. Each side has its own routing infrastructure and need routing guidance in the CID.

There is not particular reason why a client and a server should use the same CID on the same path, after all, it really is two paths, one for each direction. This also makes it possible to require CID in one direction, but not the other, or to have different routing information encoded. It would also allow each peer full control of the construction of the CID being received. This means that the peer can cryptographically reject any packet that does not have a valid CID long before any packet AEAD is applied, thus defending against a flooding attack. There is no need to negotiate any encryption for this to work, just as is the case for the server decided CID in current 17 byte CID proposal.

As to multiple connections on same tuple and regarding initial packet CID:

The initial CID should appear random, but can be any pseudo random function. The server generated CID is then NOT return in the packet header, but in a separate field, possibly in transport params. For version negotiation the initial CID is used in reply. For stateless retry the initial CID is used, but a second server CID is added to the package.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1089

---

From: ianswett <[email-masked]>
Date: Wed, 31 Jan 2018 13:46:47 -0800

I think the feeling was that this was a v2 issue, but all your points are correct and the DTLS connection ID draft proposes asymmetric connection IDs.  The main thing that needs to change for this to work as you said, is the new connection ID needs to be in Transport params or somewhere else in the handshake, opposed to replacing the connection ID of the server to client packets.

https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1089#issuecomment-362081566

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jan 2018 14:34:19 -0800

I'll copy some comments I made privately to someone who proposed this:

> It is natural to want to have this sort of design.  It's more
symmetric in my mind, since each side gets to determine what they want
to receive and sends what their peer wants.  But the effect on the
stateless reset design is unfortunate.
>
> It makes it impossible for the server to include the right connection
ID in its stateless reset.  Well, unless you encode the full client
connection ID inside the server one, which I guess is possible, though
it's a wee bit inefficient.  Importantly, that means that the server
can't guarantee that the packet reaches the client.  Given that you
just put in all that effort to ensure that the connection ID is more
usable for a client, that's unfortunate.  If you don't get exactly the
right value, it is also easier to identify that packet as a stateless
reset, but I think that's less of a concern because we already accept
some amount of fuzziness there.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1089#issuecomment-362094046

---

From: MikkelFJ <[email-masked]>
Date: Wed, 31 Jan 2018 15:09:42 -0800

Or maybe the path ID is more apt than connection ID, but I'm getting attached to that name somehow.

As to the stateless retry issue, I'm not sure a grasp all the details but I already proposed to used the cleint CID in the response and store the server chosen CID separately in the response.

However, when the client then does an initial handshake with the stateless retry, there is a problem because the initial CID is no longer client chosen. This problem can solved (for example) by reserving one bit in the CID to indicate if it is client or server chosen. If the initial handshake CID is server chosen, the client must place its own new CID in the transport params, or a separate field - which is now a fair bit of complexity, but possible.

This can be taken one step further so that each per always send the CID in transport params and the initial handshake is something else, like completely random.

There could be accidental unwanted exposure I'm missing here - e.g. that it should be hard to guess that an initial handshake was retry triggered.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1089#issuecomment-362102078