From 793c9d9d0de793d66d4ffeacbb6cad8679b296b1 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Wed, 4 Nov 2020 16:46:56 -0500 Subject: [PATCH 1/8] Generalize CID-based path validation --- draft-ietf-quic-transport.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index ed10d3ac06..377a6903c6 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1926,9 +1926,10 @@ 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. +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 +client validates the server address. Prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes they have received. This limits the From ed27b7620f4268e8992a0f3e8bb1de336cd81e34 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Wed, 4 Nov 2020 17:00:53 -0500 Subject: [PATCH 2/8] Generalize Handshake packets, too --- draft-ietf-quic-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 377a6903c6..0200a5bbcd 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1922,9 +1922,9 @@ 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. +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. 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 From 4357b4ebb304fa26cfd216e39bae95193296e78f Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Thu, 5 Nov 2020 10:25:27 -0500 Subject: [PATCH 3/8] Apply suggestions from code review Co-authored-by: Martin Thomson --- draft-ietf-quic-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0200a5bbcd..29d1e2083d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1922,9 +1922,9 @@ 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 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. +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 From 0dd1d2e0d7d907263bd34cba7826f75fc94cbb78 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 9 Nov 2020 12:00:11 +1100 Subject: [PATCH 4/8] ODCID is a special for validating the server address For #4330. --- draft-ietf-quic-transport.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 29d1e2083d..0415dbf5ee 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1928,8 +1928,9 @@ 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 -client validates the server address. +least 64 bits of entropy. For the client, the value of the Destination +Connection ID field in its first Initial packet also fulfills this requirement, +such that successfully processing any packet validates the server address. Prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes they have received. This limits the From 5def48e7760be3227472fba349c2a558dcf68fe7 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 9 Nov 2020 15:17:09 +1100 Subject: [PATCH 5/8] Magic Co-authored-by: Jana Iyengar --- draft-ietf-quic-transport.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0415dbf5ee..eff6866836 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1928,9 +1928,10 @@ 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. For the client, the value of the Destination -Connection ID field in its first Initial packet also fulfills this requirement, -such that successfully processing any packet validates the server address. +least 64 bits of entropy. A client can consider the server address validated on +successfully processing any packet received from the server, since for +encrypting its Initial packets, the server uses the Destination Connection ID +field from the client's first Initial packet; see Section 5.2 of {{QUIC-TLS}}. Prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes they have received. This limits the From 2b3a00f8a7cc84c17a45874bd3f201f8758aa750 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 9 Nov 2020 16:59:41 +1100 Subject: [PATCH 6/8] Revert "Magic" This reverts commit c06648102104f5641b68c0d2c0277f51c7b721b1. --- draft-ietf-quic-transport.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index eff6866836..0415dbf5ee 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1928,10 +1928,9 @@ 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. A client can consider the server address validated on -successfully processing any packet received from the server, since for -encrypting its Initial packets, the server uses the Destination Connection ID -field from the client's first Initial packet; see Section 5.2 of {{QUIC-TLS}}. +least 64 bits of entropy. For the client, the value of the Destination +Connection ID field in its first Initial packet also fulfills this requirement, +such that successfully processing any packet validates the server address. Prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes they have received. This limits the From 7de8e8d598703ed35d7feaedb418a8ba700f8646 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 9 Nov 2020 17:03:06 +1100 Subject: [PATCH 7/8] More words on client validation of the server address --- draft-ietf-quic-transport.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0415dbf5ee..25d8f83ad5 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1928,9 +1928,14 @@ 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. For the client, the value of the Destination -Connection ID field in its first Initial packet also fulfills this requirement, -such that successfully processing any packet validates the server address. +least 64 bits of entropy. + +For the client, the value of the Destination Connection ID field in its first +Initial packet allows it to validate the server address as a part of +successfully processing any packet. Initial packets from the server are +protected with keys that are derived from this value (see Section 5.2 of +{{QUIC-TLS}}). Alternatively, the value is echoed by the server in Retry and +Version Negotiation packets. Prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes they have received. This limits the From 67826d03807ec52e255c3fcd486205ac6f20e413 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 10 Nov 2020 14:46:09 +1100 Subject: [PATCH 8/8] Jana's text is more accurate. Co-authored-by: Jana Iyengar --- draft-ietf-quic-transport.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 25d8f83ad5..94c1275ea7 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1934,8 +1934,9 @@ For the client, the value of the Destination Connection ID field in its first Initial packet allows it to validate the server address as a part of successfully processing any packet. Initial packets from the server are protected with keys that are derived from this value (see Section 5.2 of -{{QUIC-TLS}}). Alternatively, the value is echoed by the server in Retry and -Version Negotiation packets. +{{QUIC-TLS}}). Alternatively, the value is echoed by the server in Version +Negotiation packets ({{version-negotiation}}) or included in the Integrity Tag +in Retry packets (Section 5.8 of {{QUIC-TLS}}). Prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes they have received. This limits the