Subject: [quicwg/base-drafts] Connection ID is not a number (#834)

From: Martin Thomson <[email-masked]>
Date: Wed, 04 Oct 2017 00:02:59 +0000 (UTC)

The resolution to #786 wasn't editorial.  It changed connection ID to a number, which is unnecessary.  The value is constructed by the server and echoed by the client.  If it is stored internally by clients and server, that's not really observable.

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

---

From: Patrick McManus <[email-masked]>
Date: Wed, 04 Oct 2017 00:47:26 +0000 (UTC)

we spend a lot of time saying "cid N" did something weird. If there is disagreement on how to speak N it could lead to a whole lot of confusion. I think cid really does have a number semantic.

-- 
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/834#issuecomment-334019865

---

From: Nick Banks <[email-masked]>
Date: Wed, 04 Oct 2017 13:34:42 +0000 (UTC)

+1 to treating Connection ID as a number.

-- 
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/834#issuecomment-334156714

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 04 Oct 2017 08:20:35 -0700

Completely agree.

On Tue, Oct 3, 2017 at 5:47 PM, Patrick McManus <[email-masked]>
wrote:

> we spend a lot of time saying "cid N" did something weird. If there is
> disagreement on how to speak N it could lead to a whole lot of confusion. I
> think cid really does have a number semantic.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/834#issuecomment-334019865>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ASp6ypaBBgA2O9Sp8bcpzXqBplDNn0lPks5sotWdgaJpZM4Ps75U>
> .
>

-- 
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/834#issuecomment-334191398

---

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Oct 2017 23:35:31 -0700

OK, I still disagree.  Patrick's point about logging might be valid (assuming that we do indeed have confusion there), by adding a recommendation that the value that should be logged is the hex of the bytes that appear on the wire.  That's a much smaller problem though.

BTW, numbers have mathematical operations applied to them.  Or they need to be described in terms of numbers (like version, where we define version 1 and need to know where the bit is set).  This doesn't meet either test.

-- 
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/834#issuecomment-335075327

---

From: Brian Trammell <[email-masked]>
Date: Mon, 09 Oct 2017 06:59:38 +0000 (UTC)

Agree with @martinthomson -- it doesn't seem like a good idea to ascribe any semantics to CID at the protocol level beyond "here's an opaque fixed-length byte array". How a given implementation wants to treat this is implementation-dependent. (An implementation that does wish to treat it as an encoded integer should probably treat it as big endian, following the principle of least surprise, but that's not the protocol's business)

-- 
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/834#issuecomment-335078285

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 09 Oct 2017 01:39:32 -0700

Martin and Brian's description are closer to how I intended to use CID, more like a part-GUID.

-- 
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/834#issuecomment-335096148

---

From: ekr <[email-masked]>
Date: Mon, 09 Oct 2017 07:08:34 -0700

I agree with Martin as well. The natural way to encode a bytestring is hex,
so I don't see the problem

On Mon, Oct 9, 2017 at 1:39 AM, Lucas Pardue <[email-masked]>
wrote:

> <https://github.com/quicwg/base-drafts/issues/834#issuecomment-335096148>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1od3podGUEVcBneW5h8EeuHS5h9L2ks5sqdvCgaJpZM4Ps75U>
> .
>

-- 
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/834#issuecomment-335169378

---

From: janaiyengar <[email-masked]>
Date: Mon, 09 Oct 2017 16:42:22 -0700

GQUIC interprets connection ID as a number. We talk about CID as a number and use numeric representations across our tooling. CID has always been a numeric value in GQUIC, and we just went through the pain of converting from little-endian to big-endian representation (on the wire) for this value. 

Every implementation is of course free to do as it pleases, since it's all network-byte-order on the wire and when being fed to the HKDF. So GQUIC can continue doing as it does even if the spec says that this is a bytestring, and *hopefully* nothing will break.

Which brings me to the practical reasons for keeping it as a number. Just as Patrick, we'll continue talking about connection ID 'N' and our tooling will continue referring to it as a 64-bit int. It seems natural to refer to it as a number to avoid confusion between implementations when they need to refer to this in some way for debugging.

IMO, making it a byte-string has no practical value but does seem to have the value of coloring the bikeshed with the "right" color. 

This issue is about changing the existing definition of connection ID -- which inherits GQUIC, where it is a number. I'd like to push back against it because it creates work and/or potential confusion in the future. Keeping it as a number does neither and is my preferred way forward.

(FWIW, calling it a number doesn't mean using it as a number is a useful exercise in any other way. Adding 1 to the connection ID is fun, but doesn't mean anything since the spec doesn't say anything about what that means.)

-- 
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/834#issuecomment-335318658

---

From: ekr <[email-masked]>
Date: Mon, 09 Oct 2017 23:56:34 +0000 (UTC)

It's worth noting that we've had discussions about increasing the size of the connection ID or making it arbitrary length (for instance, to accommodate self-encryption). That's not a great match for having it be an integer.

More generally, I am not sure I follow your argument here. Are you arguing that integers are inherently less confusing (this seems dubious in light of the endianness concerns you cite) or merely that they are less confusing because that's currently what's in the draft and it's confusing to change?

-- 
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/834#issuecomment-335320620

---

From: janaiyengar <[email-masked]>
Date: Tue, 10 Oct 2017 00:27:50 +0000 (UTC)

I'm saying that we (GQUIC) use Connection ID in our tooling/logging (and pretty much anywhere) as a number. There's no strong motivation to change it now for us since (i) we just went through and changed this, and (ii) it was thorny. That will leave us using it as a number and others using it as a number/byte-string, causing confusion when we talk to a non-GQUIC implementer about a 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/834#issuecomment-335324814

---

From: MikkelFJ <[email-masked]>
Date: Tue, 10 Oct 2017 07:38:25 +0000 (UTC)

OK, thought I'd stay out of this, but regarding Janas comment. It actually matters for communication/logging/debugging.

I fully agree that the ID should be thought of as a binary string, not a number, similar to how an IV vector is communicated. This means that the ID is given as a hex value similar to a SHA hash where the first two hex digits is the first byte in the string and so forth.

It also matters in the context of AEAD encryption of clear text since it is being used in the keying material. If it is a number the then numerical content is different from wire format on little endian machines, but this, I believe, is not the intent.

That being said, if implementations find it easier to read the field as a number, who would cares, as long as the keying and external communication is consistent, and as long as the ID is fixed known byte length with adequate zero padding when numbers are small.

-- 
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/834#issuecomment-335387655

---

From: martinduke <[email-masked]>
Date: Tue, 17 Oct 2017 14:49:25 -0700

This actually now has real-world implications in the -07 draft. The connection ID is an input to generate the cleartext keys, so it very much matters what order the bytes are in.

I actually don't care which way we resolve it, but we must be absolutely clear.

-- 
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/834#issuecomment-337383219