Subject: Re: [quicwg/base-drafts] Connection ID lengths 1, 2 and 3 bytes can't be encoded (#1570)

From: janaiyengar <[email-masked]>
Date: Tue, 07 Aug 2018 12:40:27 -0700

@ekr @martinthomson : I think it's useful to have this degree of freedom for uses, for instance, where there's no migration, but only demultiplexing among a few connections. I understand the concern that having connection ID that's too small can lead to linkability, but I think there's a natural pushback here -- servers that use connection ID for demuxing will want to use a large CID because small ones are not enough, or they'll use no CID. The only place a small one becomes interesting is when (i) there are only a few connections being demuxed and (ii) where the bit cost matters. This is true in the p2p case, where I would argue that linkability is quite easy with just timing of packets.

-- 
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/1570#issuecomment-411177124

---

From: ekr <[email-masked]>
Date: Tue, 07 Aug 2018 13:05:05 -0700

@janaiyengar: I'm not sure I disagree, but I feel uncomfortable going
against what I thought was consensus. Regrettably, I think a topic for NYC.

On Tue, Aug 7, 2018 at 12:40 PM, janaiyengar <[email-masked]>
wrote:

> @ekr <https://github.com/ekr> @martinthomson
> <https://github.com/martinthomson> : I think it's useful to have this
> degree of freedom for uses, for instance, where there's no migration, but
> only demultiplexing among a few connections. I understand the concern that
> having connection ID that's too small can lead to linkability, but I think
> there's a natural pushback here -- servers that use connection ID for
> demuxing will want to use a large CID because small ones are not enough, or
> they'll use no CID. The only place a small one becomes interesting is when
> (i) there are only a few connections being demuxed and (ii) where the bit
> cost matters. This is true in the p2p case, where I would argue that
> linkability is quite easy with just timing of packets.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/1570#issuecomment-411177124>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1oaQcNqm140O3BhvaRU19r3qq1c5hks5uOe0pgaJpZM4VQV65>
> .
>

-- 
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/1570#issuecomment-411184260

---

From: ianswett <[email-masked]>
Date: Tue, 07 Aug 2018 13:06:23 -0700

Personally, I'm happy with this.

-- 
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/1570#issuecomment-411184650

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 07 Aug 2018 15:04:58 -0700

In addition to linkability, the other issue with the proposal is that you could easily run out of CIDs when stateless reset is being used. Quoting from the editors' draft:

> Revealing the Stateless Reset Token allows any entity to terminate the connection, so a value can only be used once. This method for choosing the Stateless Reset Token means that the combination of connection ID and static key cannot occur for another connection.
> https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.6.13.4

Considering the two issues, I prefer not allowing shorter CID lengths in QUICv2 (formerly called v1). P2P can be a post-v2 thing.

-- 
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/1570#issuecomment-411218168

---

From: MikkelFJ <[email-masked]>
Date: Tue, 07 Aug 2018 15:06:43 -0700

I'd rather fix the text about being used once. It is not practical to track all ID's anyway - it can only be a stastical property.

-- 
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/1570#issuecomment-411218595

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Aug 2018 19:23:29 -0700

Once you get beyond 80 or so bits, collisions aren't really a practical concern, but more a theoretical one.

-- 
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/1570#issuecomment-411262428

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 07 Aug 2018 21:35:12 -0700

In addition to what @martinthomson has pointed out, I would like to note that it is possible to implement a deterministic approach for shorter CIDs (e.g. 4 octets).

One way is to let the endpoint track the CIDs for which it has generated a stateless reset, and rotate the reset key when the size of the tracked CIDs exceeds certain threshold, at the same time enforcing the active clients to switch to new CIDs (so that they can be reset using a stateless reset generated by the new key). You can use a probablistic structure (e.g. bloom filter) to track the CIDs for which stateless resets has been generated.

However, my understanding is that such approach does not work well for very short CIDs (e.g. 1 octet), because when under attack, the number space will be consumed by the attacker faster than clients migrate to new CIDs.

-- 
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/1570#issuecomment-411282149

---

From: MikkelFJ <[email-masked]>
Date: Wed, 08 Aug 2018 00:57:08 -0700

You can state that CID must not be ambigious across active connections with high propability.

As to resets, perhaps they do not make sense for short CID's.

-- 
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/1570#issuecomment-411320693

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 08 Aug 2018 04:43:48 -0700

> As to resets, perhaps they do not make sense for short CID's.

I would rephrase that to a question: do we need to give (some small number of) implementations a chance to save 3 octets, even though some features will not work if they choose to save the bytes?

I do not think it is something worth doing.

Note that in the future we could introduce very short CIDs *for short packets* in future versions of QUIC, even though we decide to not have them in QUIC v1.

-- 
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/1570#issuecomment-411377433

---

From: Mike Bishop <[email-masked]>
Date: Wed, 08 Aug 2018 09:33:44 -0700

@kazuho, also recall that the design we're discussing in the design team doesn't permit an endpoint to force a CID change on the peer.

-- 
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/1570#issuecomment-411470211