Subject: [quicwg/base-drafts] Connection ID Length changes (#2473)

From: martinduke <[email-masked]>
Date: Fri, 15 Feb 2019 09:33:13 -0800

There's nothing in the spec that prohibits this, except from zero to not zero. But should there be?

1) For the receiver, it's a bit annoying to have to store the length of each additional connection ID
2) We could eliminate the length field from the frame
3) If we're concerned about changes from zero-length being detectable, we should also be concerned about length changes being detectable. Ultimately, the complexity of handling this is the problem of the endpoint generating the connection ID, so if you want to do this to yourself, go for it. The use case for going from zero to not-zero (unexpectedly needing migration) is as relevant as changing between non-zero lengths (migrating existing connections when the routing scheme totally changes)

I would recommend one of the following:
A) New CIDs must retain the same length
B) Remove all restrictions on CID length changes - I sorta lean towards this one,  but I think both are better than the status quo.

-- 
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/2473

---

From: Nick Banks <[email-masked]>
Date: Fri, 15 Feb 2019 09:38:01 -0800

I brought this up on the PR when we added the NEW_CONNECTION_ID frame and it was decided that some folks thought it was a feature that (nonzero length) CIDs could length if they wanted...

-- 
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/2473#issuecomment-464135289

---

From: ianswett <[email-masked]>
Date: Fri, 15 Feb 2019 09:49:02 -0800

I strongly oppose A).  There are definitely cases I may want to change CID length.

I have no idea why we say you can't change from zero to non-zero lengths.  That being said, I'm not sure what the incentive is for a peer to move from zero to non-zero, so maybe restricting it doesn't matter.

-- 
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/2473#issuecomment-464138793

---

From: MikkelFJ <[email-masked]>
Date: Fri, 15 Feb 2019 09:53:01 -0800

There are routing implications going from 0 to non-zero. A 0 would be a 5-tuple hash, or so. Suddenly changing that could confuse middle boxes. It could also change some privacy assumptions made by the peer when accepting the connection.

-- 
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/2473#issuecomment-464140068

---

From: martinduke <[email-masked]>
Date: Fri, 15 Feb 2019 09:59:33 -0800

@mikkelfj This is entirely up to the endpoint generating the CIDs, yes? Endpoints already need to be aware of their routing architecture.

I don't understand the privacy implications you allude to.

-- 
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/2473#issuecomment-464142213

---

From: MikkelFJ <[email-masked]>
Date: Fri, 15 Feb 2019 18:07:58 +0000 (UTC)

A CID is a cookie that can simplify tracking compared to a translated 5-tuple that depends on hidden routing table state. A CID could also suggest that migration is suddenly undertaken even if not permitted. These are both weak arguments, but it is easier to be fooled when the CID come and go if you do not check everything carefully.

-- 
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/2473#issuecomment-464144815

---

From: Martin Thomson <[email-masked]>
Date: Fri, 15 Feb 2019 10:37:22 -0800

@ianswett, consider how an endpoint might distinguish between a short header with a zero-length connection ID and a packet with a non-zero-length connection ID. If the need to do trial decryption doesn't bother you (it is after all self-inflicted) then we can maybe allow a transition between the two, but I think that was the primary reason.

-- 
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/2473#issuecomment-464154067

---

From: ianswett <[email-masked]>
Date: Fri, 15 Feb 2019 10:41:48 -0800

Thanks, given it seems to be a core goal of the QUIC design to avoid trial decryption, that makes sense.

-- 
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/2473#issuecomment-464155411

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 15 Feb 2019 18:43:05 +0000 (UTC)

It is not clear to me what this bug is about.  @martinduke, do you propose that _NEW_CONNECTION_ID_ frames always carry CIDs of the same length for a given connection?

-- 
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/2473#issuecomment-464155858

---

From: Mike Bishop <[email-masked]>
Date: Fri, 15 Feb 2019 19:23:33 +0000 (UTC)

If you have a "mixed" connection, you lose the ability to reject packets because the CID is unknown; it might be your zero-length CID, so you have to try to process packets with unknown CIDs.  But also, if you *do* recognize the CID and it fails to decrypt, you have to decrypt it again -- it might be a ZLCID packet where the packet number happens to encrypt into a valid CID!  So I agree, let's not do that.

I don't feel strongly about requiring all CIDs on the connection to be the same length, save to note that it's not implausible for a server to reach a case where it must either kill a connection or increase the CID size being used.  (Let's say that all/enough CIDs in the previous size have been allocated already.)

-- 
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/2473#issuecomment-464168826

---

From: martinduke <[email-masked]>
Date: Fri, 15 Feb 2019 11:47:02 -0800

I don't understand the trial decryption argument.

An inherent property of zero length is that I must trial decrypt any pkt with unknown connection id, so the existence of non-zero-length IDs is orthogonal to this point.

If I have a ZL and non ZL CID, on every packet I do a simple byte compare to check which it is, then decrypt. No trial decryption required.

-- 
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/2473#issuecomment-464176277

---

From: martinduke <[email-masked]>
Date: Fri, 15 Feb 2019 11:48:17 -0800

@dtikhonov that was one proposal, but at this point it's dead. Now the proposal is for hosts with ZLCIDS to offer non-perishable length in new_conn_id frames

-- 
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/2473#issuecomment-464176691

---

From: Mike Bishop <[email-masked]>
Date: Fri, 15 Feb 2019 19:50:49 +0000 (UTC)

Zero-length is prohibited from migrating (modulo #2441), so the 4-tuple gives you quasi-similar protection against injected junk that a CID does -- to inject, you have to be able to see previous packets, hence on-path.  You're not (quite) signing up to decrypt any junk packet you get handed.

-- 
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/2473#issuecomment-464177541

---

From: martinduke <[email-masked]>
Date: Fri, 15 Feb 2019 20:09:32 +0000 (UTC)

@mikebishop I think you're describing migration with only ZLCID, which IMO would still be illegal.

If a short header comes in from a new address, simply match a known local CID, like for any other non-ZLCID connection. If no match, drop it.

-- 
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/2473#issuecomment-464183207

---

From: Mike Bishop <[email-masked]>
Date: Fri, 15 Feb 2019 12:32:07 -0800

So you're suggesting that clients MUST use a CID until the path has been validated and then MAY switch back to the zero-length CID?  Hm.  That does still have the double-decrypt case for a valid CID on an established path, but that should be vanishingly rare outside of an attack.

I'm still not convinced it's necessary, but it's possible it could be done safely.

-- 
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/2473#issuecomment-464189224

---

From: MikkelFJ <[email-masked]>
Date: Fri, 15 Feb 2019 12:33:30 -0800

Is it important/worthwhile?

-- 
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/2473#issuecomment-464189559

---

From: martinduke <[email-masked]>
Date: Fri, 15 Feb 2019 12:47:06 -0800

@mikebishop you are ahead if me and thinking about going from non ZLCID to ZLCID. That is not what I'm proposing, and would have to think about it.

For the moment, do you see a trial decryption issue if we allow ZL to nonZL transitions only?

-- 
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/2473#issuecomment-464193382

---

From: martinduke <[email-masked]>
Date: Fri, 15 Feb 2019 12:47:48 -0800

@mikkelfj why ban it we're not sure?

-- 
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/2473#issuecomment-464193582

---

From: MikkelFJ <[email-masked]>
Date: Fri, 15 Feb 2019 12:50:35 -0800

... unnecessary complexity and risk. But granted, there ought to be justifications for the requirements set.

-- 
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/2473#issuecomment-464194408

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 15 Feb 2019 14:27:09 -0800

@martinduke 
> There's nothing in the spec that prohibits this, except from zero to not zero.

Going from non-zero to zero is also prohibited. NCID cannot carry a zero-length CID. Prohibiting it makes sense, because a server can have at most one connection that uses a zero-length CID, assuming that the CID might be used for a new path (that's the intent of delivering a CID in a NCID frame).

While I think it's possible to design an endpoint that does zero-to-non-zero transition without trial decryption, I think forbidding both ways is cleaner. Is there a particular benefit in supporting zero-to-non-zero transition?

-- 
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/2473#issuecomment-464227121

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 15 Feb 2019 22:35:36 +0000 (UTC)

@martinduke 
> If a short header comes in from a new address, simply match a known local CID, like for any other non-ZLCID connection. If no match, drop it.

The issue with the approach is that the server cannot distinguish between a connection that it has lost state and a broken packet with zero-length CID. The server loses the ability to send stateless resets for all of the connections it handles.

Note: IIUC, a server is expected to generate stateless reset tokens by using 5-tuple (if CIDL=0) or by using CID (if CIDL!=0).

-- 
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/2473#issuecomment-464229906

---

From: martinduke <[email-masked]>
Date: Fri, 15 Feb 2019 14:44:05 -0800

@kazuho

> a server can have no more than one connection that uses a zero-length CID, assuming that the CID might be used for a new path (that's the intent of delivering a CID in a NCID frame).

Why not? ZLCID connections are separated by 4-tuple. One of the clients proposes a new CID. Then something comes in a new address with the CID previously proposed. It seems fairly simple to distinguish the two.

-- 
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/2473#issuecomment-464232597

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 15 Feb 2019 15:48:19 -0800

@martinduke Here's an example.

The server has two connections; A (using client address IPaddr<sub>A</sub>) and  B (using address IPaddr<sub>B</sub>). The server issues zero-length CIDs to both of the connections.

Then, when the server receives a short header packet from IPaddr<sub>C</sub> (due to either A or B migrating a new address), the server cannot tell if the packet belongs to connection A or connection B without trial decryption.

-- 
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/2473#issuecomment-464251003

---

From: Benjamin Saunders <[email-masked]>
Date: Fri, 15 Feb 2019 17:09:59 -0800

A CID from NEW_CONNECTION_ID might also be used to reduce linkability following an idle period, and if non-ZLCID to ZLCID transition were permitted, it might also be used for a client to explicitly opt-out of support for migration in exchange for reduced overhead. Initiating a migration with a ZLCID doesn't make sense, but these other cases seems reasonable to me.

-- 
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/2473#issuecomment-464267337

---

From: martinduke <[email-masked]>
Date: Sat, 16 Feb 2019 10:09:22 -0800

Either I have been very unclear, or I am proposing something that makes a simple error so that it is confusing everybody. Here is what I am proposing to allow (CIDs are letters)

Client                                                                                                    Server
[ Connection already setup; client has no CID ]
IP: 1.1.1.1 to 2.2.2.2 (DCID A) ----->
           (contains NEW_CONN_ID B)
                                                                              <--- IP: 2.2.2.2 to 1.1.1.1 (no DCID)
                                                                                       (contains NEW_CONN_ID C)
(exchange continues with IP addresses above, with no CID to client and CID A to server)
(then there's an address change)
IP: 3.3.3.3 to 2.2.2.2 (DCID C) -------->
                                                                               <---- IP: 2.2.2.2 to 3.3.3.3 (DCID B)

This is the case I am concerned about. I do not see, at the moment, any reason why switching "client" and "server" above should make a difference.

What I am definitely NOT proposing is that an endpoint migrate while never accepting a non-ZL CID.

-- 
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/2473#issuecomment-464368407

---

From: martinduke <[email-masked]>
Date: Sat, 16 Feb 2019 10:10:30 -0800

Format fail, try again

Client                                                          Server

-- 
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/2473#issuecomment-464368483

---

From: martinduke <[email-masked]>
Date: Sat, 16 Feb 2019 10:11:23 -0800

Format fail, try again

Client                        Server

-- 
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/2473#issuecomment-464368548

---

From: ianswett <[email-masked]>
Date: Sat, 16 Feb 2019 13:24:43 -0800

@kazuho The server can also statelessly reset the connection if it has no state by 5-tuple, as you mention above.

I don't have a very strong feeling on this, but it seems like another thing we forbid that has some potentially valid uses with drawbacks we don't like.  Unless we think this is actively harmful, I'd prefer to allow this.

If a server never wants to transition to/from a 0-len CID, it's easy for it to do that.

-- 
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/2473#issuecomment-464387118

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 16 Feb 2019 18:45:15 -0800

@martinduke 
> Either I have been very unclear, or I am proposing something that makes a simple error so that it is confusing everybody. Here is what I am proposing to allow (CIDs are letters)

I think it works, though I wonder why the client needs to switch to using a zero-length client CID when it migrates. Can't it just continue using a zero-length client CID?

@ianswett 
> The server can also statelessly reset the connection if it has no state by 5-tuple, as you mention above.

Please let me retract that, because it's wrong. The design of stateless reset requires the source of the reset token to not be reused. That's something the sender of stateless reset can enforce when using CIDs, but not when relying on the 5-tuple. Quoting from section 10.4.2 of the transport draft: _This design relies on the peer always sending a connection ID in its packets so that the endpoint can use the connection ID from a packet to reset the connection. An endpoint that uses this design MUST either use the same connection ID length for all connections or encode the length of the connection ID such that it can be recovered without state. In addition, it cannot provide a zero-length connection ID._

> I don't have a very strong feeling on this, but it seems like another thing we forbid that has some potentially valid uses with drawbacks we don't like. Unless we think this is actively harmful, I'…

I would not oppose to allowing it, though the premise would be that it does not introduce complexity to other implementations that would not be using the feature, because I do not understand the practical benefit.

-- 
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/2473#issuecomment-464410321

---

From: martinduke <[email-masked]>
Date: Sat, 16 Feb 2019 20:00:28 -0800

@kazuho To avoid trial decryption!

-- 
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/2473#issuecomment-464414423

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 16 Feb 2019 23:38:08 -0800

@martinduke IIUC, generally speaking, trial decryption becomes inevitable for a client when it coalesces multiple connections that uses the same server 2-tuple onto a single socket.

In the approach you describe, the client is not coalescing multiple connections in such a way on a single socket when it initiates the connection, because it is initially using zero-length CID. But it sounds like that the client will be using the socket in such a way on a socket it decides to migrate.

What I do not see is the rationale behind such a design.

If the client's preference is to minimize the network bandwidth (by using zero-length CIDs), shouldn't it use zero-length CIDs for subsequent paths that it migrates the connection to? That's possible, as long as it does not coalesce multiple connections that share the same server 2-tuple onto a single socket. The simplest way of doing that is to use a dedicated socket for each connection.

Or if the client's preference is to minimize the number of sockets it maintains, shouldn't it be always using non-zero-length CIDs from when it initiates a new connection?

-- 
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/2473#issuecomment-464425588

---

From: David Schinazi <[email-masked]>
Date: Thu, 21 Feb 2019 11:47:45 -0800

I think banning switching from non-zero-length CID to zero-length CID might be too constraining. Imagine a server is initially reached via an IPv6 anycast address, and it tells the client its IPv6 preferred address. If that server owns a /64, it can give a different preferred address to each client which allows zero-length CIDs and migration without requiring trial decryption because the server can find the connection simply by looking at the packet destination IP address. (Note that kernels don't let you easily do that today but that can be fixed.) The only downside I'm seeing here is that migration can now be tracked across paths since the connection ID doesn't change and the server IP is enough to identify a connection. I suspect there are deployment scenarios where reducing CID overhead is more important that the privacy risk. But, given that the server preferred address is only advisory, a client that cares more about privacy than about the CID overhead can simply refuse to switch over. With all that said, I don't think the restriction against zero-length-CID helps us.

-- 
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/2473#issuecomment-466140260

---

From: Martin Thomson <[email-masked]>
Date: Sat, 23 Feb 2019 11:38:46 -0800

I'm willing to concede that a server preferred address is a special case here.  Destination IP address is accessible, if awkward to get at.

There is also a valid argument that says that you get what you ask for.

Either way, I don't see this being resolved here effectively.  You could raise this on the list or wait until Prague to discuss in person.

-- 
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/2473#issuecomment-466684100