Subject: [quicwg/base-drafts] Permit 0-RTT after Retry and VN (#1514)

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

After the discussion on #1507, I've been convinced that there is no real
value in preventing a client from attempting 0-RTT after a Retry.  And,
it would seem like Version Negotiation has essentially the same
properties, so excluding it would be inconsistent.

This allows this, explores the consequences for packet numbers (don't
reset them!), and updates the recovery text to include Version
Negotiation.

Closes #1507.

(Note the target of this PR.  Two pieces of work are in flight here.  Don't just merge and walk away or something could get lost.)
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Permit 0-RTT after Retry and VN

-- File Changes --

    M draft-ietf-quic-recovery.md (12)
    M draft-ietf-quic-transport.md (50)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1514.patch
https://github.com/quicwg/base-drafts/pull/1514.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/1514

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 02 Jul 2018 23:11:07 -0700

kazuho commented on this pull request.

> @@ -770,6 +776,28 @@ are in a different packet number space to other packets (see
 {{packet-numbers}}).

+### 0-RTT Packet Numbers {#retry-0rtt-pn}
+
+Packet numbers for 0-RTT protected packets use the same space as 0-RTT protected

"as 0-RTT protected" -> "as 1-RTT protected"?

-- 
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/1514#pullrequestreview-133859269

---

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

@martinthomson pushed 1 commit.

5c5e948  0-RTT, 1-RTT, same thing

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1514/files/3b756980be074f9bf8115737a4ad1e95802d747c..5c5e94894a70d5c837e5b9db8c79216acf1ceaae

---

From: Nick Banks <[email-masked]>
Date: Tue, 03 Jul 2018 13:22:26 +0000 (UTC)

nibanks 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/1514#pullrequestreview-133993657

---

From: MikkelFJ <[email-masked]>
Date: Tue, 03 Jul 2018 06:49:58 -0700

mikkelfj commented on this pull request.

> @@ -727,16 +732,17 @@ Connection ID.
 
 ### Tokens
 
-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.
+If the client has an token received in a NEW_TOKEN frame on a previous

a token

> @@ -601,6 +601,11 @@ 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 client MAY attempt 0-RTT after receiving a Retry packet by sending 0-RTT
+packets to the connection ID provided by the server.  A client that sends
+additional 0-RTT packets MUST NOT reset the packet number to 0 after a Retry
+packet, see {{retry-0rtt-pn}}.
+

sugg: A server MAY reject a redirected 0-RTT attempt because the DCID does not match the 0-RTT token.

-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 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.

Redundant explanation using both "correlate" and "linked" in separate sentences.

-- 
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/1514#pullrequestreview-134002355

---

From: ianswett <[email-masked]>
Date: Tue, 03 Jul 2018 06:54:53 -0700

ianswett approved this pull request.

 ### Tokens

a?

 {{packet-numbers}}).

+### 0-RTT Packet Numbers {#retry-0rtt-pn}
+
+Packet numbers for 0-RTT protected packets use the same space as 1-RTT protected
+packets.
+
+After a client receives a Retry or Version Negotiation packet, it MAY attempt to
+send data in 0-RTT packets after it sends a new Initial packet.  However, a
+client MUST NOT reset the packet number it uses for 0-RTT packets.  The keys
+used to protect 0-RTT keys are not guaranteed to change as a result of

Technically, I don't think there's even a mechanism the 0-RTT keys could be changed via Retry, so I'd say "not likely 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/pull/1514#pullrequestreview-133997309

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Jul 2018 16:05:37 -0700

7a72a4d  Clarify key changes

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1514/files/5c5e94894a70d5c837e5b9db8c79216acf1ceaae..7a72a4d9a0fbbcc6bcf5f7addad3d3e6ae594e2f

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Jul 2018 16:06:26 -0700

martinthomson commented on this pull request.

Not sure that I understand the suggestion.

-- 
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/1514#discussion_r199972532

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Jul 2018 16:08:55 -0700

{{packet-numbers}}).

I struggled with finding the right words, but I have a plan now.  They won't change unless the cryptographic handshake does.  (And I will leave unsaid the reasons why it might not - we have reason to believe that Retry will never cause a change and VN might, but that detail is elsewhere and if we follow the justification rabbit-hole to the end we'll be singing about oysters in no time.)

-- 
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/1514#discussion_r199972899

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Jul 2018 23:41:29 -0700

59247b3  Redo fixes I already committed somewhere else, I swear

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1514/files/7a72a4d9a0fbbcc6bcf5f7addad3d3e6ae594e2f..59247b308b7456ae09e2a7a6b53ad46a7f2d5ccb

---

From: Mike Bishop <[email-masked]>
Date: Thu, 05 Jul 2018 09:19:45 -0700

MikeBishop requested changes on this pull request.

I eventually figured out what you actually meant, but it didn't click for me reading the text the first time.  If it's not just me, perhaps more/different explanation is in order.

The key point is that if the CID doesn't change, the 0-RTT packets from before and after the Retry can both be accepted and processed as part of the connection, either via buffering or reordering.  So you have to resend all that data, but can't reuse those packet numbers.

-The Retry indicates that the Initial was received but not processed.  It MUST
-NOT be treated as an acknowledgment for the Initial, but it MAY be used for an
-RTT measurement.
+Either packet indicates that the Initial was received but not processed.  Either
+packet cannot be treated as an acknowledgment for the Initial, but they MAY be

"Either ... cannot" feels awkward.  Maybe "Neither packet can be...."?

> @@ -727,16 +732,16 @@ Connection ID.
 
 ### Tokens
 
-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.
+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.

This paragraph looks like a rewrap to a shorter line length than the rest of the document.  The original layout appears to be fine.

-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 client SHOULD NOT reuse a token.  Reusing a token could allow different
+connections to be identified as coming from the same endpoint (see also
+{{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 MUST start the connection

I know you didn't change this text, but this seems to preclude clients keeping a cache of tokens and the associated network connections.  For example, a mobile device that went to Wi-Fi could keep the cellular token in expectation that it will be on cellular again.  Perhaps the better prohibition is that you MUST NOT use the token on a different network than where you received it?

> @@ -770,6 +775,29 @@ are in a different packet number space to other packets (see
 {{packet-numbers}}).

If the CID doesn't change, reordering or caching could cause the first flight of 0-RTT packets to remain valid after the new Initial lands.  So unless the CID changes (and maybe even if it does, if the server is trying too hard), you have to assume those packets are still outstanding but potentially lost.  Maybe we should frame this in terms of fast retransmit?

> @@ -1311,6 +1339,10 @@ Version Negotiation packet.
 A client MUST ignore a Version Negotiation packet that lists the client's chosen
 version.
 
+A client MAY attempt 0-RTT after receiving a Version Negotiation packet.  A
+client that sends additional 0-RTT packets MUST NOT reset the packet number to 0
+after a Retry packet, see {{retry-0rtt-pn}}.

Since this section is about Version Negotiation packets, the mention of Retry packets seems a *non sequitur*.  It's fine to reset the 0-RTT packet number space after a VN packet, because the previous 0-RTT packets will be of a version unknown to the server and therefore will just be discarded (or rather, will trigger more VN 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/pull/1514#pullrequestreview-134717567

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Jul 2018 17:16:57 -0700

It's not OK to reset the packet numbers, because you just created a two-time pad.  The same key and nonce, with different inputs (the version number).  That's disastrous.

The mention of Retry is a mistake though.

-- 
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/1514#discussion_r200521788

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Jul 2018 17:23:12 -0700

{{packet-numbers}}).

I realize now the source of the confusion.  You are concerned about the case where maybe all this 0-RTT is received (and can be processed).  I'm more concerned about catastrophic compromise of packet protection.  I think that the nonce reuse thing is more urgent.

-- 
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/1514#discussion_r200522553

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Jul 2018 17:23:46 -0700

7c68e0b  Refinements

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1514/files/59247b308b7456ae09e2a7a6b53ad46a7f2d5ccb..7c68e0b867d08c801fd93abdffa4bd4305414c53

---

From: Mike Bishop <[email-masked]>
Date: Thu, 05 Jul 2018 19:51:36 -0700

MikeBishop approved this pull request.

Regardless of urgency, I think this covers both cases a little 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/1514#pullrequestreview-134874008

---

From: MikkelFJ <[email-masked]>
Date: Thu, 05 Jul 2018 21:47:49 -0700

Me neither - the thought was to use the dcid given in the retry - which could lead to a target that does not accept the tokens. But dcid cannot change from when tikens were forged.

-- 
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/1514#discussion_r200548444

---

From: MikkelFJ <[email-masked]>
Date: Thu, 05 Jul 2018 21:47:49 -0700

-- 
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/1514#discussion_r200548447

---

From: MikkelFJ <[email-masked]>
Date: Thu, 05 Jul 2018 21:50:54 -0700

I think it does not matter if the packet got to a server - but it might have gotten to an attacker.

-- 
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/1514#issuecomment-402924883

---

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

janaiyengar commented on this pull request.

> @@ -770,6 +776,33 @@ are in a different packet number space to other packets (see
 {{packet-numbers}}).

+### 0-RTT Packet Numbers {#retry-0rtt-pn}
+
+Packet numbers for 0-RTT protected packets use the same space as 1-RTT protected
+packets.
+
+After a client receives a Retry or Version Negotiation packet, 0-RTT packets are
+likely to be lost or discarded by the server, especially if the server changes

s/likely to be/likely to have been/

> @@ -770,6 +776,33 @@ are in a different packet number space to other packets (see
 {{packet-numbers}}).

+### 0-RTT Packet Numbers {#retry-0rtt-pn}
+
+Packet numbers for 0-RTT protected packets use the same space as 1-RTT protected
+packets.
+
+After a client receives a Retry or Version Negotiation packet, 0-RTT packets are
+likely to be lost or discarded by the server, especially if the server changes
+its connection ID with a Retry packet.  A client MAY attempt to send data in

s/send data/resend data/

> @@ -731,12 +736,13 @@ 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.
 
+its point of network attachment has changed since it was last used; that is, if

This seems too strong -- see my comment on the other PR.

-- 
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/1514#pullrequestreview-135179550

---

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Jul 2018 16:53:48 -0700

1ae029a  Have been

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1514/files/7c68e0b867d08c801fd93abdffa4bd4305414c53..1ae029af1d7148396c2f312dc20e8262d34445d3

---

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Jul 2018 21:32:55 -0700

80779d8  Add text to the TLS spec too

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1514/files/1011f5ee62e300237373931b4b2aa23fff19c9cd..80779d89df2f5006f2e663df1b764e311f72ed07

---

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

25598fd  Extra 'on'

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1514/files/2e13f0d6461c75a74c92d11fe07b83bcebfa0ed8..25598fd7d7e6906030b99315b09a5e41aa2ce7af

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 09 Jul 2018 00:06:24 -0700

> @@ -778,6 +783,33 @@ are in a different packet number space to other packets (see
 {{packet-numbers}}).

+### 0-RTT Packet Numbers {#retry-0rtt-pn}
+
+Packet numbers for 0-RTT protected packets use the same space as 1-RTT protected
+packets.
+
+After a client receives a Retry or Version Negotiation packet, 0-RTT packets are
+likely to have been lost or discarded by the server, especially if the server
+changes its connection ID with a Retry packet.  A client MAY attempt to resend

The text after "especially if ..." seems to imply that 0-RTT packets might not have been lost in case the client receives a Version Negotiation packet.

I am not sure if that is true.

My understanding is that a Version Negotiation packet is sent by a server only if the client offers a version unknown to the server. In such case, all the 0-RTT packets would have been lost, because the format of the 0-RTT packets are version specific, and those would have been unprocessible by 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/pull/1514#pullrequestreview-135295742

---

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

22deb75  Remove especially if text

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1514/files/25598fd7d7e6906030b99315b09a5e41aa2ce7af..22deb75449751fd21fd75c48fdbbf16d94665daa

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Jul 2018 03:00:15 -0700

{{packet-numbers}}).

Yeah, this is right.  In order of likelihood that packets are unusable:

1. VN with unsupported version
2. Retry w/ connection ID change
3. Retry w/o connection ID change or VN with preferred alternative version

I don't know why I missed that.  Reworded.

-- 
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/1514#discussion_r200946722

---

From: ianswett <[email-masked]>
Date: Mon, 09 Jul 2018 08:46:27 -0700

LGTM

-- 
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/1514#pullrequestreview-135477846

---

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

Merged #1514.

-- 
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/1514#event-1761808151