Subject: [quicwg/base-drafts] Equivalence of preferred_address and NEW_CONNECTION_ID (#3560)

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2020 17:14:01 -0700

We don't prohibit the use of a zero-length connection ID in the preferred_address transport parameter.  

So a server can use a connection ID during connection establishment, then remove privacy protections by moving to a unique address (see #3559).  Of course, this is largely moot, as the privacy protection offered through the use of connection IDs toward a unique address is nil.

In either case, we should clarify whether preferred_address is exactly like NEW_CONNECTION_ID, or whether it has its own rules.  Right now, it looks like it has its own rules and that is likely bad.

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

---

From: Marten Seemann <[email-masked]>
Date: Mon, 30 Mar 2020 18:41:12 -0700

Zero-length connection IDs don't have a stateless reset token associated with them, but the preferred_address TP requires you to set a token. That's an awkward corner case.

-- 
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/3560#issuecomment-606346565

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2020 20:14:58 -0700

That is just one of the strange things, yeah.  We should clarify 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/3560#issuecomment-606373327

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Mar 2020 19:38:37 -0700

So I see a number of ways forward here:

1. Do nothing.  Leave this ambiguous and potentially special.

2. Make the fields in preferred_address exactly equivalent to a NEW_CONNECTION_ID with a sequence number of 1.  But allow the connection ID to be zero-length.  A zero-length connection ID provides a new stateless reset token that is bound to the new address.  (This is a weird option that would go against previous decisions to eliminate special handling for this connection ID, but I include it for the sake of completeness.)

3. As 2, except that the new stateless reset token has connection-wide scope such that either of the provided tokens can be used.  This is more consistent with established principles.

4. Prohibit the use of zero-length connection IDs in preferred_address.  That is, you can't use preferred_address without a connection ID.  That is, preferred_address effectively is a new server address plus a NEW_CONNECTION_ID frame.

5. Something else.

>From my perspective, I rank these as 4 > 3  >> 1 > 2.  But that is largely based on my bias against zero-length connection IDs (as much as it seems like that might be good for privacy, I think that privacy is better served by the use of connection IDs).  If people intend to use preferred_address to migrate to a connection-specific address, then I'm OK with 3; we already have #3563 to cover the privacy hole that arises from 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/3560#issuecomment-606992985

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 31 Mar 2020 20:13:16 -0700

My preference goes to option 4 too.

I do not think servers would use both 0-byte CID and preferred_address TP at the same time. The only case a server using 0-byte CID can also use preferred_address is:
* when the server is never accepting more than one connection at a time, or
* when the server knows that the client's address tuple does not change when the client migrates to a new address

IMO that's a niche. And when these cases can be met, I do not see why the client cannot know the preferred address of the server beforehand.

-- 
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/3560#issuecomment-607002366

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Mar 2020 20:52:07 -0700

I forgot to add: There is (maybe) a case for using a connection ID during setup and a zero-length connection ID after migrating to a preferred address.  That isn't entirely crazy, but I personally would be comfortable losing that option.  But I don't operate a server, so I want to give those who do a chance to let me know that this is preemptive.

-- 
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/3560#issuecomment-607012900

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 31 Mar 2020 21:44:54 -0700

@martinthomson My personal take would be that people would not do that. When a client migrates to the preferred address, there's fair chance that the client's address tuple will change. That means that the server should be capable of receiving short header packets with 0-byte CID from any address, and determine that the packet belongs to the connection that is migrating to the preferred address.

That's possible theoretically, but in practice ...

I agree that a server might want to switch to zero-byte CID _after_ migration to SPA completes. But to do that, we need a NEW_CONNECTION_ID that can carry a zero-byte CID, which is forbidden at the moment. I do not think we'd want to change the spec now to allow 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/3560#issuecomment-607028938

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Mar 2020 22:29:04 -0700

That's an excellent point, and a good reason not to allow changing to zero-length connection IDs in combination with preferred_address.  The nasty part of that is that in most cases that design would work because clients won't use the "new" connection ID until after the handshake is complete.  Of course, it would fail spectacularly if a client did decide to switch earlier - and the client might attract the blame, where it is clearly the fault of the 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/3560#issuecomment-607040794