Subject: [quicwg/base-drafts] All the Retry-related fixes (#1788)

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Sep 2018 16:52:29 -0700

Except the one where we will authenticate it.  That comes afterwards.

Closes #1784, #1709.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Just one Retry
  * Force the server to change connection ID on Retry

-- File Changes --

    M draft-ietf-quic-transport.md (106)

-- Patch Links --

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

---

From: MikkelFJ <[email-masked]>
Date: Sat, 22 Sep 2018 00:17:57 -0700

mikkelfj commented on this pull request.

-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.
+Clients MUST discard Retry packets that contain an Original Destination
+Connection ID field that does not match the Destination Connection ID its

of its

> @@ -739,9 +742,10 @@ Source Connection IDs during the handshake.
 
 On first receiving an Initial or Retry packet from the server, the client uses
 the Source Connection ID supplied by the server as the Destination Connection ID
-for subsequent packets.  Once a client has received an Initial packet from the
-server, it MUST discard any packet it receives with a different Source
-Connection ID.
+for subsequent packets.  That means that a client might change the Destination
+Connection ID twice during connection establishment.  Once a client has received

only twice? Is there text to prevent a server from issuing a retry when a retry token is present in initial?

-- 
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/1788#pullrequestreview-157901674

---

From: Martin Thomson <[email-masked]>
Date: Sat, 22 Sep 2018 09:36:09 -0700

martinthomson commented on this pull request.

There is nothing stopping the server from sending multiple Retry packets (regardless of which flight they came from, whether they had token, or anything).  However, the client is only going to process one of 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/1788#discussion_r219676378

---

From: Martin Thomson <[email-masked]>
Date: Sat, 22 Sep 2018 09:37:44 -0700

@martinthomson pushed 1 commit.

422c1df  this was missing word

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1788/files/6bfc1ffa4e3155df109cc0afdfc36dc690c2fdfc..422c1df11adb32d0a21bcaddc1a4fa20952fb7ae

---

From: MikkelFJ <[email-masked]>
Date: Sat, 22 Sep 2018 10:08:36 -0700

right

-- 
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/1788#discussion_r219677160

---

From: ianswett <[email-masked]>
Date: Sun, 23 Sep 2018 06:16:07 -0700

ianswett commented on this pull request.

Thanks Martin, looks good.

> @@ -593,37 +593,40 @@ 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.
+field.  This value MUST not be equal to the Destination Connection ID field of

So the server HAS to change connection ID with a Retry?  I have no problem with that, but I wasn't sure where that ended up previously.

-A Retry packet does not include a packet number and cannot be explicitly
-acknowledged by a client.
+A server MAY send Retry packets in response to Initial and 0-RTT packets.  A
+server can either discard or buffer 0-RTT packets that it receives.  A server

Below, you're advising that the client changes crypto context in response to Retry, so buffering 0RTT packets is likely to be useless, correct?

Retry is really meant for cheap DDoS, so if we want this to work well, I think we should spend more time thinking about how to make it work well.  I suspect we don't care and should just advise dropping 0RTT packets if you're sending a Retry?

-A server MUST NOT send a Retry in response to packets other than Initial
-or 0-RTT packets.  A server MAY choose to only send Retry in response to Initial
-packets and discard or buffer 0-RTT packets corresponding to unvalidated client
-addresses.
+A client MUST accept and process at most one Retry packet for each connection

This MUST is a bit strong for me when thinking of man-on-the-side, especially since you don't respond to cases when the original dcid doesn't match, but it's Ok for now since mots is out of scope for 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/pull/1788#pullrequestreview-157937587

---

From: MikkelFJ <[email-masked]>
Date: Sun, 23 Sep 2018 07:23:05 -0700

What about perferect forward secrecy - could there be an issue with crypto reuse 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/1788#discussion_r219700505

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Sep 2018 09:17:07 -0700

Yes, this isn't obvious until you read #1784.  In that case, the reuse of a connection ID causes the client to be confused about what belongs to what.

The problem @tatsuhiro-t identified is that the client can respond to a Retry, then receive a valid Initial in response to a packet sent before that Retry, but it is one that is incompatible with its current TLS state.  This assumes that the client has changed its ClientHello somehow in response to the Retry, which we encourage, but don't mandate.

Forcing the change of connection ID means that a client that receives a Retry will drop anything sent by the server in response to any Initial packets sent before receiving the Retry.  So, if a retransmission of the first round of Initial packets gets a real response, that will just be dropped.

-- 
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/1788#discussion_r219703682

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Sep 2018 09:19:45 -0700

Yeah, I thought about that.  The way to finagle this is to think of the defense against spoofed Retry as forking off multiple connections.  Each Retry you decide to process makes another connection.

-- 
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/1788#discussion_r219703735

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Sep 2018 09:20:35 -0700

Yes, the recommendation causes 0-RTT packets to be unusable at the server.  I think that's OK, the text below makes the trade-off 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/pull/1788#discussion_r219703751

---

From: MikkelFJ <[email-masked]>
Date: Sun, 23 Sep 2018 10:04:26 -0700

At some point it was suggested that a man-on-the-side defence could be to excercise the retry, but still watch out of an initial response within a timeout period. If an initial response arrives, the retry is cancelled. But I guess you could have bogus inital responses to valid retries ...

-- 
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/1788#discussion_r219704899

---

From: ianswett <[email-masked]>
Date: Sun, 23 Sep 2018 11:56:53 -0700

Agreed, it seems like the right solution, can you call this and the fact we're limiting to 1 Retry in the PR description, because those are fairly substantial changes?

-- 
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/1788#discussion_r219708061

---

From: ianswett <[email-masked]>
Date: Sun, 23 Sep 2018 18:57:10 +0000 (UTC)

ianswett 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/1788#pullrequestreview-157948323

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Sep 2018 14:12:11 -0700

Merged #1788 into master.

-- 
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/1788#event-1862138253