Subject: [quicwg/base-drafts] Remove the explicit packet number gap in favor of one computed (#496)

From: ekr <[email-masked]>
Date: Wed, 03 May 2017 10:18:15 -0700

based on a shared secret.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/496

-- Commit Summary --

  * Remove the explicit packet number gap in favor of one computed

-- File Changes --

    M draft-ietf-quic-tls.md (10)
    M draft-ietf-quic-transport.md (54)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/496.patch
https://github.com/quicwg/base-drafts/pull/496.diff

-- 
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/pull/496

---

From: ekr <[email-masked]>
Date: Wed, 03 May 2017 10:52:06 -0700

@martinthomson: I note that this change means that these don't need to be delivered to the client where they did before.

Also, I wonder if we should allow multiple conn_ids to be delivered in the same frame, thus saving some bits.

-- 
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/pull/496#issuecomment-298985908

---

From: Martin Thomson <[email-masked]>
Date: Wed, 03 May 2017 15:24:09 -0700

martinthomson approved this pull request.

I like this, it removes bytes on the wire at the cost of a few hashes.  Let's change the encoding for the packet later.  I agree that packing 255 new connection IDs in a single frame probably makes more sense now that you don't have an explicit gap.  A length-prefixed list is always smaller for N>1, especially since you can share the sequence number.

However, if we are going to do #460 or #20, then we might also need some way to include an updated verifier for the public reset.  That's going to create less incentive to send enough new connection IDs and the simpler frame might be easier in that case.

Let's see what others think.

>  between two points of network attachment.
 
-The NEW_CONNECTION_ID message includes a connection ID that the client can use
-for packets on the current connection.  This message also includes packet number
-gap, which is the number of packet numbers that the client skips when using the
-new connection ID.  Without this, the packet number field in the header might be
-used to link activity across networks.  A server MUST provide a 32-bit value for
-the packet number gap field that is indistinguishable from random to a passive
-observer.
+A client which wishes to break linkability upon changing networks MUST
+use the NEW_CONNECTION_ID as well as incrementing the packet sequence

`MUST use the NEW_CONNECTION_ID` implies sending, it's the value from the message that the client uses.

I'm not sure about the MUST-requirement.  Isn't this a simple "can"?

> @@ -1296,6 +1291,22 @@ connection ID, it should expect packets on the new connection ID to start at 18.
 A packet with the new connection ID and a packet number of 17 is discarded as
 being in error.
 
+#### Packet Number Gap
+
+In order to avoid linkage, the packet number gap MUST be externally
+indistinguishable from random. The packet number gap for a connection
+ID with sequence number is computed by encoding the sequence number
+as a 32-bit integer in big-endian format, and then computing:

Since packet numbers are 64-bit, might as well make this the same type.  HKDF won't care.

-- 
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/pull/496#pullrequestreview-36152313

---

From: ekr <[email-masked]>
Date: Wed, 03 May 2017 15:26:22 -0700

ekr commented on this pull request.

Well I think my claim is that if you want it unlinkable you have 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/pull/496#discussion_r114667708

---

From: ekr <[email-masked]>
Date: Wed, 03 May 2017 15:26:46 -0700

+#### Packet Number Gap
+

Yeah, agreed.

-- 
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/pull/496#discussion_r114667768

---

From: janaiyengar <[email-masked]>
Date: Wed, 03 May 2017 16:44:43 -0700

janaiyengar commented on this pull request.

A couple of comments

The MUST is unclear. I'm not sure how to read it -- is this a requirement of the spec? Seems not, since according to the text, a client may choose to not break linkability. Perhaps using lowercase "must" is what you want here?

+#### Packet Number Gap
+
+In order to avoid linkage, the packet number gap MUST be externally
+indistinguishable from random. The packet number gap for a connection
+ID with sequence number is computed by encoding the sequence number
+as a 32-bit integer in big-endian format, and then computing:
+
+~~~
+Gap = HKDF-Expand-Label(packet_number_secret,
+                        "QUIC packet sequence gap", sequence, 4)

HKDF-Expand-Label is not defined in the transport draft. This should be one more addition to the QUIC-TLS API. 

-- 
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/pull/496#pullrequestreview-36161486

---

From: janaiyengar <[email-masked]>
Date: Wed, 03 May 2017 16:44:32 -0700

Nice -- I like this quite a bit! On compressing, as martinthomson@ points out we haven't settled yet.  I would suggest leaving it as is, and open an issue for (later) looking into > 1 IDs per NEW_CONNECTION_ID frame.

-- 
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/pull/496#issuecomment-299065962

---

From: Martin Thomson <[email-masked]>
Date: Wed, 03 May 2017 17:10:55 -0700

martinthomson commented on this pull request.

+#### Packet Number Gap
+

I don't think you want that.  The API we agreed on previously was that TLS provides an exporter and the transport uses it.  If you want this to be in TLS, then we end up with a much tighter coupling than you would like.  (Me, I don't care, I don't see any point in disentangling these two parts, but we did have consensus to separate them.)

-- 
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/pull/496#discussion_r114681126

---

From: ekr <[email-masked]>
Date: Wed, 03 May 2017 17:37:37 -0700

+#### Packet Number Gap
+

@janaiyengar, is what you want here:

"The TLS-QUIC API must expose a function QUIC-Packet-Gap(sequence) -> Gap which returns a 32-bit integer indicating the packet gap for a given sequence 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/pull/496#discussion_r114683521

---

From: janaiyengar <[email-masked]>
Date: Wed, 03 May 2017 18:14:27 -0700

+#### Packet Number Gap
+

Hm -- good point martinthomson@ -- I hadn't thought about that. Is it adequate to do some sort of simple hash here then?

-- 
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/pull/496#discussion_r114686560

---

From: Martin Thomson <[email-masked]>
Date: Wed, 03 May 2017 18:16:55 -0700

+#### Packet Number Gap
+

@ekr's design is best practice here.  I would not be that happy about a design that was less robust than this.  HKDF has a bunch of features that we might not need, but the alternatives would require considerably more analysis before we could be sure that they are OK.

-- 
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/pull/496#discussion_r114686754

---

From: janaiyengar <[email-masked]>
Date: Wed, 03 May 2017 18:23:38 -0700

+#### Packet Number Gap
+

Why wouldn't a simple keyed-hash be adequate? Of course, organization of text shouldn't determine our design; do you have a suggestion for organizing the text if HKDF is to be used?

-- 
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/pull/496#discussion_r114687201

---

From: Martin Thomson <[email-masked]>
Date: Wed, 03 May 2017 18:27:55 -0700

+#### Packet Number Gap
+

If we move packet protection to the transport, as planned, then we'll need HKDF, so there's no real issue with taking this change as it is.

-- 
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/pull/496#discussion_r114687492

---

From: ekr <[email-masked]>
Date: Wed, 03 May 2017 20:02:58 -0700

+#### Packet Number Gap
+

"keyed hash" isn't really a well-formed cryptographic construct. What you want here is a PRF, and these days that typically means using HMAC (which is what HKDF is under the covers). So, if you really prefer, we could inline the HMAC expansion of HKDF-Expand-Label, but I'm not really seeing what the benefit of that is in this instance, given that, as Martin says, if we move packet protection into this document, we'll need HKDF anyway.

Jana, it might help me if it were a bit clearer about what you were optimizing for here. Any implementation of this document is going to need HKDF (and even if you were to swap out TLS, it's quite likely you would end up using HKDF), so it's not really implementation complexity, so is it just that you don't like having a citation to some construct exposed by TLS? If so, that seems like something we can deal with much later in the document cycle if we still feel that way.

-- 
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/pull/496#discussion_r114693283

---

From: janaiyengar <[email-masked]>
Date: Thu, 04 May 2017 16:50:42 -0700

+#### Packet Number Gap
+

Yeah, both of your responses make sense. Thanks for helping me understand.

-- 
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/pull/496#discussion_r114912295

---

From: janaiyengar <[email-masked]>
Date: Thu, 04 May 2017 16:51:01 -0700

janaiyengar approved this pull request.

-- 
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/pull/496#pullrequestreview-36414342

---

From: Martin Thomson <[email-masked]>
Date: Sun, 07 May 2017 18:08:35 -0700

Merged #496.

-- 
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/pull/496#event-1072072833