Subject: [quicwg/base-drafts] Generalize CID-based path validation (#4330)

From: Mike Bishop <[email-masked]>
Date: Wed, 04 Nov 2020 13:49:11 -0800

Fixes #4259.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Generalize CID-based path validation

-- File Changes --

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

-- Patch Links --

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 04 Nov 2020 14:01:33 -0800

@MikeBishop pushed 1 commit.

ed27b7620f4268e8992a0f3e8bb1de336cd81e34  Generalize Handshake packets, too

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4330/files/793c9d9d0de793d66d4ffeacbb6cad8679b296b1..ed27b7620f4268e8992a0f3e8bb1de336cd81e34

---

From: Mike Bishop <[email-masked]>
Date: Wed, 04 Nov 2020 14:03:54 -0800

The issue suggests that _any_ packet from the server validates the server's address, because it echoes the client's CID.  I'm not sure that's correct, because the client might have chosen a zero-length SCID in its initial packet, and the server doesn't echo the ODCID in Initial packets.

This PR generalizes the existing rules for servers -- receiving a sufficiently-complex DCID or a valid Handshake packet is actual proof of address ownership.

-- 
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/4330#issuecomment-721999420

---

From: Martin Thomson <[email-masked]>
Date: Wed, 04 Nov 2020 18:46:25 -0800

@martinthomson approved this pull request.

With tweaks (and likely a rewrap), this is good.

> @@ -1922,13 +1922,14 @@ validation is performed both during connection establishment (see
 
 Connection establishment implicitly provides address validation for both
 endpoints.  In particular, receipt of a packet protected with Handshake keys
-confirms that the client received the Initial packet from the server.  Once the
-server has successfully processed a Handshake packet from the client, it can
-consider the client address to have been validated.
-
-Additionally, a server MAY consider the client address validated if the
-client uses a connection ID chosen by the server and the connection ID contains
-at least 64 bits of entropy.
+confirms that the peer received an endpoint's Initial packet.  Once an endpoint

```suggestion
confirms that the peer successfully processed an Initial packet.  Once an endpoint
```

> @@ -1922,13 +1922,14 @@ validation is performed both during connection establishment (see
 
 Connection establishment implicitly provides address validation for both
 endpoints.  In particular, receipt of a packet protected with Handshake keys
-confirms that the client received the Initial packet from the server.  Once the
-server has successfully processed a Handshake packet from the client, it can
-consider the client address to have been validated.
-
-Additionally, a server MAY consider the client address validated if the
-client uses a connection ID chosen by the server and the connection ID contains
-at least 64 bits of entropy.
+confirms that the peer received an endpoint's Initial packet.  Once an endpoint
+has successfully processed a Handshake packet from the peer, it can consider the
+peer's address to have been validated.

```suggestion
peer address to have been validated.
```

-- 
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/4330#pullrequestreview-523887654

---

From: Mike Bishop <[email-masked]>
Date: Thu, 05 Nov 2020 07:25:51 -0800

3041ad9356ad44955b8119170b18cbaa4594eb99  Apply suggestions from code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4330/files/ed27b7620f4268e8992a0f3e8bb1de336cd81e34..3041ad9356ad44955b8119170b18cbaa4594eb99

---

From: Mike Bishop <[email-masked]>
Date: Thu, 05 Nov 2020 07:27:32 -0800

4357b4ebb304fa26cfd216e39bae95193296e78f  Apply suggestions from code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4330/files/3041ad9356ad44955b8119170b18cbaa4594eb99..4357b4ebb304fa26cfd216e39bae95193296e78f

---

From: ianswett <[email-masked]>
Date: Fri, 06 Nov 2020 04:19:36 -0800

@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/4330#pullrequestreview-525101694

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 06 Nov 2020 16:33:19 -0800

@janaiyengar commented on this pull request.

One question, but otherwise, lgtm.

> +least 64 bits of entropy.  This means that any valid packet received by the
+client validates the server address.

We don't seem to define "valid packet" anywhere. Do we have a definition?

-- 
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/4330#pullrequestreview-525569427

---

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Nov 2020 01:09:17 -0800

@martinthomson commented on this pull request.

Successfully processed, perhaps 

-- 
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/4330#discussion_r519308149

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 08 Nov 2020 15:34:49 -0800

@kazuho commented on this pull request.

 Connection establishment implicitly provides address validation for both
 endpoints.  In particular, receipt of a packet protected with Handshake keys
-confirms that the client received the Initial packet from the server.  Once the
-server has successfully processed a Handshake packet from the client, it can
-consider the client address to have been validated.
-
-Additionally, a server MAY consider the client address validated if the
-client uses a connection ID chosen by the server and the connection ID contains
-at least 64 bits of entropy.
+confirms that the peer successfully processed an Initial packet.  Once an
+endpoint has successfully processed a Handshake packet from the peer, it can
+consider the peer address to have been validated.
+
+Additionally, an endpoint MAY consider the peer address validated if the peer
+uses a connection ID chosen by the endpoint and the connection ID contains at
+least 64 bits of entropy.  This means that any valid packet received by the

I think there is a disconnect between the two sentences.

First sentence talks about the peer using the connection ID chosen by the endpoint. But the second sentence tries to derive from the first sentence that the original DCID chosen by the client, which is _never_ chosen as a connection ID by the server, working as a proof.

I think it might make sense to preserve the second paragraph as-is, then add a separate paragraph pointing out that a client validates the server's address when receiving a Initial packet that can be successfully processed, because the protection keys are derived from the client-chosen DCID that is at least 64 bits long.

-- 
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/4330#pullrequestreview-525858116

---

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Nov 2020 17:01:55 -0800

This is a good point.  I've a proposal inbound that doesn't add sentences, but rewrites the second instead.

Retry or Version Negotiation are included, but by virtue of their inclusion as a Source Connection ID, not the Initial packet protection.

-- 
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/4330#discussion_r519505439

---

From: Mike Bishop <[email-masked]>
Date: Mon, 09 Nov 2020 08:22:21 -0800

@MikeBishop pushed 4 commits.

0dd1d2e0d7d907263bd34cba7826f75fc94cbb78  ODCID is a special for validating the server address
5def48e7760be3227472fba349c2a558dcf68fe7  Magic
2b3a00f8a7cc84c17a45874bd3f201f8758aa750  Revert "Magic"
7de8e8d598703ed35d7feaedb418a8ba700f8646  More words on client validation of the server address

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4330/files/4357b4ebb304fa26cfd216e39bae95193296e78f..7de8e8d598703ed35d7feaedb418a8ba700f8646

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 09 Nov 2020 16:46:31 -0800

> +{{QUIC-TLS}}).  Alternatively, the value is echoed by the server in Retry and
+Version Negotiation packets.

It is not echoed in the Retry packet - it is included in the Retry Pseudo-packet over which the integrity tag is computed.

-- 
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/4330#pullrequestreview-526767852

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 09 Nov 2020 17:01:32 -0800

```suggestion
{{QUIC-TLS}}). Additionally, the value is echoed by the server in Version
Negotiation packets ({{version-negotiation}}), and included in the Integrity Tag
in Retry packets (Section 5.8 of {{QUIC-TLS}}).
```

-- 
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/4330#pullrequestreview-526773766

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Nov 2020 19:46:28 -0800

@martinthomson pushed 1 commit.

67826d03807ec52e255c3fcd486205ac6f20e413  Jana's text is more accurate.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4330/files/7de8e8d598703ed35d7feaedb418a8ba700f8646..67826d03807ec52e255c3fcd486205ac6f20e413

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 09 Nov 2020 20:43:19 -0800

@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/4330#pullrequestreview-526848536

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 10 Nov 2020 06:53:23 -0800

@kazuho 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/4330#pullrequestreview-527283113

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 10 Nov 2020 15:07:47 -0800

Merged #4330 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/4330#event-3981343306