Subject: Re: [quicwg/base-drafts] Rework Retry packet (#1498)

From: Mike Bishop <[email-masked]>
Date: Mon, 02 Jul 2018 16:41:31 -0700

MikeBishop commented on this pull request.

> @@ -532,6 +532,86 @@ See {{version-negotiation}} for a description of the version negotiation
 process.

+## Retry Packet {#packet-retry}
+
+A Retry packet uses the invariant portion of the long packet header with a type

"Invariant portion of the long packet header" feels awkward.  The invariants specify what a long header looks like, and this draft specifies additional fields which are in certain types.  The "Long Header" section actually adds additional fields beyond the long header which are type-specific to most (but not all) packet types used by this version.  Maybe the real subdivision is "Retry Packets" and "Connection Setup Packets", along with a reminder than Version Negotiation packets are defined in invariants?

> + 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+
+|1|    0x7e     |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                         Version (32)                          |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|DCIL(4)|SCIL(4)|
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|               Destination Connection ID (0/32..144)         ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                 Source Connection ID (0/32..144)            ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|    ODCIL(8)   |      Original Destination Connection ID (*)   |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                        Retry Token (*)                      ...

Technically, you could; just that, like a short-header packet, the Retry would have to come last.  But as you say, I can't imagine a use for it in this version of QUIC, and since these are version-specific packets....

> +|                         Version (32)                          |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|DCIL(4)|SCIL(4)|
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|               Destination Connection ID (0/32..144)         ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                 Source Connection ID (0/32..144)            ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|    ODCIL(8)   |      Original Destination Connection ID (*)   |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                        Retry Token (*)                      ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+{: #retry-format title="Retry Packet"}
+
+A Retry packet (shown in {{retry-format}}) only the invariant portion of the

This is duplicative of the first sentence in this section.  Perhaps condense?

> +
+Retry Token:
+
+: An opaque token that the server can use to validate the client's address.
+
+The server populates the Destination Connection ID with the connection ID that
+the client included in the Source Connection ID of the Initial packet.
+
+The server includes a connection ID of its choice in the Source Connection ID
+field.  The client MUST use this connection ID in the Destination Connection ID
+of subsequent packets that it sends.
+
+A Retry packet does not include a packet number and cannot be explictly
+acknowledged by a client.
+
+A server MUST only send a Retry in response to a client Initial packet.

I'm not even sure it's necessary for it to be a SHOULD; there's no interoperability risk if it sends a Retry in response to a lone 0-RTT packet, is there?  In which case it sounds more like servers MAY omit sending Retry in response to 0-RTT when they haven't seen the Initial.

> +
+A Retry packet does not include a packet number and cannot be explictly
+acknowledged by a client.
+
+A server MUST only send a Retry in response to a client Initial packet.
+
+If the Original Destination Connection ID field does not match the Destination
+Connection ID from most recent the Initial packet it sent, clients MUST discard
+the packet.  This prevents an off-path attacker from injecting a Retry packet
+with a bogus new Source Connection ID.
+
+The client responds to a Retry packet with Initial packet that includes the
+provided Retry Token to continue connection establishment.
+
+A server that might send another Retry packet in response to a subsequent
+Initial packet MUST set the Source Connection ID to new value of at least 8

@nibanks, it's the other way around.  "A server that might send another" => all but the last.  If you don't know you're the last element in the chain, you MUST change the CID.  (Presumably to something that will get the retransmitted packet further down the DDoS chain.)

 A server sends its first Initial packet in response to a client Initial.  A
 server may send multiple Initial packets.  The cryptographic key exchange could
 require multiple round trips or retransmissions of this data.
 
 The payload of an Initial packet includes a CRYPTO frame (or frames) containing
 a cryptographic handshake message, ACK frames, or both. The first CRYPTO frame
-sent always begins at an offset of 0 (see {{handshake}}). The client's complete
-first message MUST fit in a single packet (see {{handshake}}). Note that if the
-server sends a HelloRetryRequest, the client will send a second Initial packet
-with a CRYPTO frame with an offset starting at the end of the CRYPTO stream in
-the first Initial.
+sent always begins at an offset of 0 (see {{handshake}}).
+
+The first packet sent by a client always includes a CRYPTO frame that contains
+the first cryptographic handshake message.  The first packet sent by a client
+MUST fit in a single UDP datagram (see {{handshake}}).

Tautological, since we have no mechanism for a packet to span datagrams.  But the first TLS message must fit in the first packet.

-- 
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/1498#pullrequestreview-133807792

---

From: Martin Thomson <[email-masked]>
Date: Mon, 02 Jul 2018 21:43:05 -0700

martinthomson commented on this pull request.

-If the client has a suitable token available from a previous connection, it
-SHOULD populate the Token field.
+A client MUST NOT reuse a token if it believes that its point of network

I wasn't clear enough.  I think that it's SHOULD NOT reuse (blanket), and MUST NOT reuse if the client moves.

-- 
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/1498#discussion_r199682024

---

From: Martin Thomson <[email-masked]>
Date: Mon, 02 Jul 2018 21:49:36 -0700

@martinthomson pushed 1 commit.

55e910f  Address various comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1498/files/bf3f67597f3315018d348bfcf638d8fb9379ff0f..55e910f476f56ede4f13ff506378f74a0e488444

---

From: MikkelFJ <[email-masked]>
Date: Mon, 02 Jul 2018 21:54:30 -0700

mikkelfj commented on this pull request.

> @@ -726,16 +727,17 @@ Connection ID.
 
 ### Tokens
 
-If the client has an unused token that it received in a NEW_TOKEN frame on a
-previous connection to what it believes to be the same server, it includes that
-value in the Token field of its Initial packet.
+If the client has an token received in a NEW_TOKEN frame on a previous

an

-- 
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/1498#pullrequestreview-133848576

---

From: MikkelFJ <[email-masked]>
Date: Mon, 02 Jul 2018 21:57:13 -0700

-A client MUST NOT reuse a token if it believes that its point of network
-attachment has changed; that is, if there is a change in its local IP address or
-network interface.  Reusing a token on different network paths would allow
-activity to be linked between paths (see {{migration-linkability}}).  A client
-needs to start the connection process over if it migrates prior to completing
-the handshake.
+A client SHOULD NOT reuse a token; reused tokens enable activity on connections
+to be correlated.  A client MUST NOT reuse a token if it believes that its point
+of network attachment has changed; that is, if there is a change in its local IP
+address or network interface.  Reusing a token on different network paths would
+allow activity to be linked between paths (see {{migration-linkability}}).  A
+client needs to start the connection process over if it migrates prior to
+completing the handshake.

Two separate sentences about linking, one stating "correlate", the other "linked".

-- 
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/1498#pullrequestreview-133848896

---

From: Martin Thomson <[email-masked]>
Date: Mon, 02 Jul 2018 22:11:39 -0700

Oops, thanks.

-- 
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/1498#discussion_r199684985

---

From: Martin Thomson <[email-masked]>
Date: Mon, 02 Jul 2018 22:11:48 -0700

fdb837f  Collapse a few things

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1498/files/55e910f476f56ede4f13ff506378f74a0e488444..fdb837fc8cd9b20486007f377411ff8fb98f1066

---

From: Martin Thomson <[email-masked]>
Date: Mon, 02 Jul 2018 22:28:09 -0700

dd13b0e  Add PN offset calculation adjustment for Initial packet

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1498/files/fdb837fc8cd9b20486007f377411ff8fb98f1066..dd13b0e26724445d20353a8eb382a99edc5734cc

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Jul 2018 21:21:45 -0700

c96058f  Grammar hard

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1498/files/dd13b0e26724445d20353a8eb382a99edc5734cc..c96058fc6423de0fa332f09cd500b68e1fd5ca36

---

From: janaiyengar <[email-masked]>
Date: Fri, 06 Jul 2018 16:08:27 -0700

janaiyengar commented on this pull request.

+~~~
+{: #retry-format title="Retry Packet"}
+
+A Retry packet (shown in {{retry-format}}) only uses the invariant portion of
+the long packet header {{QUIC-INVARIANTS}}; that is, the fields up to and
+including the Destination and Source Connection ID fields.  The contents of the
+Retry packet are not protected.  Like Version Negotiation, a Retry packet
+contains the long header including the connection IDs, but omits the Length,
+Packet Number, and Payload fields.  These are replaced with:
+
+ODCIL:
+
+: The length of the Original Destination Connection ID field as an unsigned
+  8-bit integer.  This field does not use the same encoding as the DCIL and SCIL
+  fields.

Can we keep the encoding the same as the DCIL? It's unnecessary, I agree, but it seems cleaner, since all CILs are then similarly encoded.

+Retry Token:
+

I don't think there's much value in sending Retry in response to 0RTT packets. Sending it without decrypting the incoming packet makes me queasy, and sending it a few times after receiving the Initial sounds like a strange retransmission strategy. It's easy to see a server generating a ton of Retry packets in response to Initial + 0RTT packets, so it seems reasonable to recommend better behavior here, and I like the text that's there. I don't mind weakening it to a SHOULD though.

+
+Connection ID from the most recent Initial packet it sent, clients MUST discard
+the packet.  This prevents an off-path attacker from injecting a Retry packet.

missing "an"

+
+If the Original Destination Connection ID field does not match the Destination
+Connection ID from the most recent Initial packet it sent, clients MUST discard
+the packet.  This prevents an off-path attacker from injecting a Retry packet.
+
+The client responds to a Retry packet with Initial packet that includes the
+provided Retry Token to continue connection establishment.
+
+A server that might send another Retry packet in response to a subsequent
+Initial packet MUST set the Source Connection ID to new value of at least 8
+octets in length.  This allows clients to distinguish between Retry packets when
+the server sends multiple rounds of Retry packets.  A server that will not send
+additional Retry packets can set the Source Connection ID to any value.  A
+client MUST ignore a Retry that contains an ODCIL field with a value less than
+8 or greater than 18.

Move this last sentence to the description of ODCIL above.

 Token Length:
 
 : A variable-length integer specifying the length of the Token field, in bytes.
-  It may be zero if no token is present. Initial packets sent by the server
-  MUST include a zero-length token.
+  This value is zero if no token is present.  Initial packets sent by the server
+  MUST specify a token of zero length.

"token length of zero"?

-If the client has a suitable token available from a previous connection, it
-SHOULD populate the Token field.
+If the client has a token received in a NEW_TOKEN frame on a previous connection
+to what it believes to be the same server, it can include that value in the
+Token field of its Initial packet.
+
+A client SHOULD NOT reuse a token.  Reusing a token on different network paths
+would allow activity to be linked between paths (see {{migration-linkability}}).
+A client MUST NOT reuse a token if it believes that its point of network

This seems a bit strong. If the client has a token that was sent under crypto cover (NEW_TOKEN as against Retry), it seems reasonable to use it on a new network path.

-- 
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/1498#pullrequestreview-135156702

---

From: Christian Huitema <[email-masked]>
Date: Sun, 08 Jul 2018 11:00:55 -0700

huitema approved this pull request.

I like these changes. Can we adopt them as baseline for the 7th interop? The retry mechanism of draft-13 is pretty hard to implement without those.

> @@ -745,6 +745,9 @@ handled separately.
 sample_offset = 6 + len(destination_connection_id) +
                     len(source_connection_id) +
                     len(payload_length) + 4
+if packet_type == Initial:
+    sample_offset += len(token_length) +
+                     len(token)
 ~~~

Unless I am missing something, len(token_length) is only available *after* the PN has been decrypted.

> @@ -745,6 +745,9 @@ handled separately.
 sample_offset = 6 + len(destination_connection_id) +
                     len(source_connection_id) +
                     len(payload_length) + 4
+if packet_type == Initial:
+    sample_offset += len(token_length) +
+                     len(token)
 ~~~

So we have a circular dependency when decrypting. See issue #1535.

+~~~

I agree with @janaiyengar. Having the same encoding would remove error conditions such as 1<=ODCIL<=3, or ODCIL>18. But of course it would introduce the error "(ODCIL&0xF0)!=0". So maybe it is a wash.

> @@ -745,6 +745,9 @@ handled separately.
 sample_offset = 6 + len(destination_connection_id) +
                     len(source_connection_id) +
                     len(payload_length) + 4
+if packet_type == Initial:
+    sample_offset += len(token_length) +
+                     len(token)
 ~~~

My bad. This is actually addressed later, as the token has now moved in front of the PN.

>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            Token (*)                        ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                           Length (i)                        ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                     Packet Number (8/16/32)                   |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                          Payload (*)                        ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Yes. This new design solves issue #1535.

@janaiyengar , no, this is not too strong. There is a real privacy risk to reusing tokens in different contexts. This is pretty similar to the privacy issues with TCP Fast Open, or with TLS resume. Encryption of New Token provides protection against on path elements, but it does not provide protection against the server itself.

-- 
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/1498#pullrequestreview-135240081

---

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Jul 2018 17:02:28 -0700

@martinthomson pushed 2 commits.

e375657  Redo ODCIL encoding.  Closes #1535.
555ae81  Tweak language

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1498/files/c96058fc6423de0fa332f09cd500b68e1fd5ca36..555ae817e5e7fb37dfb1167d08c37c8ecf901dc0

---

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Jul 2018 17:12:42 -0700

Using the token implies willingness to be tracked by the server.  I've tweaked the language accordingly.  New text on breaking tracking by the server, and tighter language on reuse.

-- 
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/1498#discussion_r200859837

---

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Jul 2018 17:13:30 -0700

19174cf  Grammar fixes, leftover invalid text
21f9ba5  Refine token use and reuse constraints

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1498/files/555ae817e5e7fb37dfb1167d08c37c8ecf901dc0..21f9ba5250712726f1112695a8d8a168a567c693

---

From: ianswett <[email-masked]>
Date: Tue, 10 Jul 2018 16:37:02 -0700

ianswett commented on this pull request.

+Retry Token:
+

Bump for changing this to a SHOULD for now?

-- 
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/1498#discussion_r201527879

---

From: ianswett <[email-masked]>
Date: Tue, 10 Jul 2018 16:37:34 -0700

-The first Initial packet contains a packet number of 0. Each packet sent after
-the Initial packet is associated with a packet number space and its packet
-number increases monotonically in that space (see {{packet-numbers}}).
+The first Initial packet sent by either endpoint contains a packet number of

Or MUST contain?

-- 
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/1498#discussion_r201527987

---

From: Christian Huitema <[email-masked]>
Date: Tue, 10 Jul 2018 20:10:56 -0700

huitema commented on this pull request.

Certainly not MUST. Consider the case where the Initial packet is resent after a version negotiation, or repeated after time-out. Then the "natural" value of the sequence number will be 1. I don't see how saying "must be zero" would improve interoperability. 

-- 
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/1498#discussion_r201553912

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jul 2018 21:16:59 -0700

Christian got it.  MUST doesn't work, and throwing normative language at this is too heavy.  I think that this is fine.

-- 
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/1498#discussion_r201560742

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jul 2018 21:18:32 -0700

+Retry Token:
+

I prefer to leave this as SHOULD for now, but will open a new issue.  This wasn't the focus of this change (this is not my text), so let's have an explicit discussion about 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/pull/1498#discussion_r201560907

---

From: Mike Bishop <[email-masked]>
Date: Wed, 11 Jul 2018 13:20:20 -0700

> @@ -568,9 +568,11 @@ Packet Number, and Payload fields.  These are replaced with:
 
 ODCIL:
 
-: The length of the Original Destination Connection ID field as an unsigned
-  8-bit integer.  This field does not use the same encoding as the DCIL and SCIL
-  fields.
+: The length of the Original Destination Connection ID field.  The length is
+  encoded in the least significant bit of the octet using the same encoding as

Needs more than one bit.

+additional Retry packets can set the Source Connection ID to any value.

But it's already rejecting a ODCID that doesn't match what it picked, and it has to have picked something >= 8 bytes, no?

> @@ -731,12 +733,18 @@ If the client has a token received in a NEW_TOKEN frame on a previous connection
 to what it believes to be the same server, it can include that value in the
 Token field of its Initial packet.
 
-A client SHOULD NOT reuse a token.  Reusing a token on different network paths
-would allow activity to be linked between paths (see {{migration-linkability}}).
-A client MUST NOT reuse a token if it believes that its point of network
-attachment has changed; that is, if there is a change in its local IP address or
-network interface.  A client needs to start the connection process over if it
-migrates prior to completing the handshake.
+A token allows a server to correlate activity between connections.
+Specifically, the connection where the token was issued, and any connection
+where it is used.  Clients that want to break continuity of identity with a
+server MAY discard tokens provided using the NEW_TOKEN frame.  Tokens obtained
+in Retry packets MUST NOT be discarded.

The prohibition below is on using a token on two different network paths.  But since the token is likely to contain address validation information, should we recommend against using the token from a different address than the one where it was received?  Or is that solely a risk of server tracking and it's covered in the privacy-from-server paragraph here?

-- 
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/1498#pullrequestreview-136404800

---

From: MikkelFJ <[email-masked]>
Date: Wed, 11 Jul 2018 13:28:23 -0700

minor: to `a` new value

-- 
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/1498#discussion_r201828632

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jul 2018 17:12:37 -0700

I thought that I caught that already.

ekr is right, if you send the first Initial with DCIL>=8 and the server respects this rule, then you will never ever get a Retry with ODCIL>=8.

mikkel, any value is correct.  The server can keep the old value if that suits it.

Yes, the intent of this paragraph is to cover that.  The paragraph below is privacy-from-network.

-- 
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/1498#discussion_r201876185

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jul 2018 17:12:40 -0700

7d96aa9  FOUR bits
dbc58a1  ODCIL will never be <8

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1498/files/21f9ba5250712726f1112695a8d8a168a567c693..dbc58a158b1bbeb2043d2224e2eba01bc38b6347

---

From: MikkelFJ <[email-masked]>
Date: Wed, 11 Jul 2018 23:49:18 -0700

@martinthomson I thought it was a typo, missing an `a` not a question about semantics.

-- 
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/1498#discussion_r201925585

---

From: Mike Bishop <[email-masked]>
Date: Thu, 12 Jul 2018 08:21:57 -0700

+
+The client responds to a Retry packet with an Initial packet that includes the

@martinthomson, @mikkelfj's comment was directed to this line -- "to **a** new value"

-- 
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/1498#pullrequestreview-136702186

---

From: Martin Thomson <[email-masked]>
Date: Sat, 14 Jul 2018 06:49:57 -0700

cd9cdb4  a new value

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1498/files/dbc58a158b1bbeb2043d2224e2eba01bc38b6347..cd9cdb48daea18b3f9b10e3459df09e833dcad32

---

From: Marten Seemann <[email-masked]>
Date: Wed, 18 Jul 2018 14:39:40 +0000 (UTC)

marten-seemann commented on this pull request.

This might be a bit esoteric, but here's possible use cases:
Let's say a server only support QUIC v1, and it receives an Initial packet for a different version. The server would then send a Version Negotiation Packet, and could coalesce that with a Retry packet, in order to save one round trip.
I admit feels kind of clumsy though, since the Retry would have to go *in front of* the VNP (since the VNP doesn't have a length field).

-- 
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/1498#discussion_r203405159

---

From: Christian Huitema <[email-masked]>
Date: Wed, 18 Jul 2018 08:20:00 -0700

@Marten: I am not sure this is a valid use case. The main use case for the retry packet is that it is sent by some kind of firewall as part of DOS defense. 

The VN is sent end-to-end, and already carries a token of sorts with the Source CID. I don't see the use case of sending both retry and VN end to end.

-- 
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/1498#discussion_r203421467

---

From: Marten Seemann <[email-masked]>
Date: Wed, 18 Jul 2018 08:25:41 -0700

In p2p, you won't have a separate firewall, but a peer might still want to use the Retry mechanism if it's under attack. I'm aware that this is not a very strong argument, since in that case you'd probably be ok with incurring an additional RTT, on the other hand, adding a varint to the header doesn't cost us a lot either.

-- 
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/1498#discussion_r203423595

---

From: Nick Banks <[email-masked]>
Date: Wed, 18 Jul 2018 14:16:18 -0700

nibanks commented on this pull request.

+Initial packet MUST set the Source Connection ID to a new value of at least 8
+the server sends multiple rounds of Retry packets.  Consequently, a valid Retry

Instead of requiring the server to use a new CID, why not just make the client use a new random CID for every new token it sends in the Initial packet? That way the client has direct control to be able to differentiate between the possibly Retry responses? And no additional complexity on the server side.

Going further, I was thinking during the talks today, if we are going to recommend that initial packet routing not take the client Initial's DCID into account (because it would be an attack surface) then I don't see any reason to support the Retry packet changing the CID at all. The primary reason for adding that support initially was for routing/load balancing; but that seems to be ill advised now. It just adds unnecessary complexity in the client code, IMO.

-- 
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/1498#pullrequestreview-138442601

---

From: MikkelFJ <[email-masked]>
Date: Wed, 18 Jul 2018 23:18:48 -0700

@nibanks 

> Instead of requiring the server to use a new CID, why not just make the client use a new random CID for every new token it sends in the Initial packet? 

The clients source SCID must be new. The clients original DCID is always new and random in an initial packet. Only the source is reflected back by the server. this is why it must be new. The alternative would be to have a separate nonce in the handshake, separate from SCID, which is what I suggest.

On the going further: The server must set is own SCID - otherwise the server is forced to use a client chosen SCID which is not only a load balancer issue and it also goes against the point of a retry. A retry is a redirect to another server, not try again until you get lucky, although that can also be implemented if the server randomizes its SCID.

-- 
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/1498#discussion_r203612261

---

From: Nick Banks <[email-masked]>
Date: Thu, 19 Jul 2018 06:31:13 -0700

@mikkelfj if the client uses a new SCID then it would be considered an entirely new connection, and might elicit another Retry. I am talking about removing the requirement from the server in generating new random CID, and instead have the client generate a new random DCID for each try.

Also, on the going further, I am only talking about Retry. After that, in the handshake the server can/will change the CID to whatever it wants.

-- 
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/1498#discussion_r203726146

---

From: MikkelFJ <[email-masked]>
Date: Thu, 19 Jul 2018 15:04:10 +0000 (UTC)

There is nothing wrong with getting a new retry, the problem is stopping when too many happen. If the client changes SCID each time, it can stop after 1-3 retries - but it helps if it can know that all retries are from the same chain. I think a nonce is better for 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/pull/1498#discussion_r203762552

---

From: Nick Banks <[email-masked]>
Date: Thu, 19 Jul 2018 08:06:58 -0700

The client should not change its SCID each time. See #1474 and the associated PR #1491.

-- 
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/1498#discussion_r203763562

---

From: MikkelFJ <[email-masked]>
Date: Thu, 19 Jul 2018 08:08:38 -0700

Which is why I think a nonce works better

-- 
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/1498#discussion_r203764238

---

From: Nick Banks <[email-masked]>
Date: Thu, 19 Jul 2018 15:10:53 +0000 (UTC)

The client's DCID is essentially the nonce, and it will always be random 8 bytes for each Retry. I am still unclear why you think that's not enough.

-- 
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/1498#discussion_r203765114

---

From: MikkelFJ <[email-masked]>
Date: Thu, 19 Jul 2018 15:14:30 +0000 (UTC)

The clients original DCID disappears once it reaches the server. Since the server sets its own SCID and the client is not allowed to change its SCID, the context is lost.
While I agree that not changing SCID is a good thing, I wondered why that was made a requirement before solving this loss of context here.
Your proposal to modify servers SCID seems like a workaround for the fundamental problem that some nonce is required. But I dont' recall all the concerns related to this right now.

-- 
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/1498#discussion_r203766499

---

From: Nick Banks <[email-masked]>
Date: Thu, 19 Jul 2018 08:20:46 -0700

I am considering only the Retry scenario right now. During the handshake, after the Retry, the server has the opportunity to change its SCID once again (independent of if it was changed during Retry). I am trying to make two points:

1. I don't see any reason for the server to generate a new, random SCID (client's DCID) with Retry. The client itself can handle creating a new random DCID when it retries.
2. Since we are going to recommend NOT load balancing off the client's initial SCID, then there is no reason to use Retry (for load balancing purposes) to change the CID at all.

-- 
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/1498#discussion_r203768707

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Jul 2018 18:58:51 -0700

@nibanks, I think that the idea was to give the server better control over where to send subsequent Retry packets.  That is, it can choose a value that is better for load, DoS prevention, or whatever it needs.  The server can use the token to validate that the value was its own choice as well, removing concerns about the client stacking load on certain servers.

(I thought that this was one of your design constraints, but I realize now I don't know where that idea came from.)

-- 
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/1498#discussion_r205999174

---

From: Nick Banks <[email-masked]>
Date: Sun, 29 Jul 2018 19:40:59 -0700

I believe @mcmanus originally requested the ability to change CID with the (old) Retry packet. For DoS, I only require the Token field. 

Is it true or not that we recommend not using the client Initial CID for load balancing decisions?

-- 
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/1498#discussion_r206003142

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Jul 2018 20:44:58 -0700

Ack.

I don't think that we have a concrete statement about using the Destination Connection ID from the client Initial.  With a token from Retry, you could; without, it's fraught, I agree.

-- 
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/1498#discussion_r206009122

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Jul 2018 22:13:10 -0700

Merged #1498.

-- 
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/1498#event-1761807164