From 78e114baa28c8be34eb0c5792893beec2c688db7 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 23 Dec 2020 10:46:49 +1100 Subject: [PATCH 1/9] Clarify definition of off-path We weren't being consistent. This should help. Next step is to ensure that our usage is consistent. --- draft-ietf-quic-transport.md | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index e896545bfa..cc9eb8e724 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -6502,11 +6502,13 @@ change or other modification in the path taken by packets that comprise a connection. Attackers are additionally categorized as either on-path attackers or off-path -attackers; see Section 3.5 of {{?SEC-CONS}}. An on-path attacker can read, +attackers. An on-path attacker can read, modify, or remove any packet it observes such that it no longer reaches its destination, while an off-path attacker observes the packets, but cannot prevent the original packet from reaching its intended destination. Both types of -attackers can also transmit arbitrary packets. +attackers can also transmit arbitrary packets. This definition differs from +that of Section 3.5 of {{?SEC-CONS}} in that an off-path attacker is able to +observe packets. Properties of the handshake, protected packets, and connection migration are considered separately. @@ -6706,21 +6708,22 @@ An off-path attacker can: An off-path attacker cannot: -- Modify any part of a packet +- Modify packets sent by endpoints - Delay packets - Drop packets - Reorder original packets -An off-path attacker can modify packets that it has observed and inject them -back into the network, potentially with spoofed source and destination -addresses. +An off-path attacker can create modified copies of packets that it has observed +and inject those copies into the network, potentially with spoofed source and +destination addresses. For the purposes of this discussion, it is assumed that an off-path attacker -has the ability to observe, modify, and re-inject a packet into the network -that will reach the destination endpoint prior to the arrival of the original -packet observed by the attacker. In other words, an attacker has the ability to -consistently "win" a race with the legitimate packets between the endpoints, -potentially causing the original packet to be ignored by the recipient. +has the ability to observe and re-inject a modified copy of a packet into the +network that will reach the destination endpoint prior to the arrival of the +original packet observed by the attacker. In other words, an attacker has the +ability to consistently "win" a race with the legitimate packets between the +endpoints, potentially causing the original packet to be ignored by the +recipient. It is also assumed that an attacker has the resources necessary to affect NAT state, potentially both causing an endpoint to lose its NAT binding, and an From 123edd6acdb98396f3e144b580e9b06f73069537 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 23 Dec 2020 10:50:27 +1100 Subject: [PATCH 2/9] Consistency in off-path usage: -transport --- draft-ietf-quic-transport.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index cc9eb8e724..fd838c8b7d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4258,8 +4258,9 @@ Path Maximum Transmission Unit Discovery (PMTUD; {{!RFC1191}}, {{!RFC8201}}) relies on reception of ICMP messages (e.g., IPv6 Packet Too Big messages) that indicate when an IP packet is dropped because it is larger than the local router MTU. DPLPMTUD can also optionally use these messages. This use of ICMP messages -is potentially vulnerable to off-path attacks that successfully guess the -addresses used on the path and reduce the PMTU to a bandwidth-inefficient value. +is potentially vulnerable to attacks by elements that cannot observe packets, +but might successfully guess the addresses used on the path. These attacks +could reduce the PMTU to a bandwidth-inefficient value. An endpoint MUST ignore an ICMP message that claims the PMTU has decreased below QUIC's smallest allowed maximum datagram size. @@ -4271,7 +4272,7 @@ actually be smaller, or the information unintelligible, as described in Section 1.1 of {{!DPLPMTUD}}. QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect from -off-path injection as specified in {{!RFC8201}} and Section 5.2 of {{!RFC8085}}. +packet injection as specified in {{!RFC8201}} and Section 5.2 of {{!RFC8085}}. This validation SHOULD use the quoted packet supplied in the payload of an ICMP message to associate the message with a corresponding transport connection (see Section 4.6.1 of {{!DPLPMTUD}}). ICMP message validation MUST include matching @@ -4648,8 +4649,8 @@ packet it receives in the Destination Connection ID field. The value for Source Connection ID MUST be copied from the Destination Connection ID of the received packet, which is initially randomly selected by a client. Echoing both connection IDs gives clients some assurance that the server received the packet -and that the Version Negotiation packet was not generated by an off-path -attacker. +and that the Version Negotiation packet was not generated by an entity that +did not receive the Initial packet. Future versions of QUIC could have different requirements for the lengths of connection IDs. In particular, connection IDs might have a smaller minimum @@ -4727,7 +4728,7 @@ In order to prevent tampering by version-unaware middleboxes, Initial packets are protected with connection- and version-specific keys (Initial keys) as described in {{QUIC-TLS}}. This protection does not provide confidentiality or integrity against on-path attackers, but provides some level of protection -against off-path attackers. +against attackers that cannot also receive packets. The client and server use the Initial packet type for any packet that contains an initial cryptographic handshake message. This includes all cases where a new @@ -4935,9 +4936,9 @@ from the server, it MUST discard any subsequent Retry packets that it receives. Clients MUST discard Retry packets that have a Retry Integrity Tag that cannot be validated; see the Retry Packet Integrity section of {{QUIC-TLS}}. This -diminishes an off-path attacker's ability to inject a Retry packet and protects -against accidental corruption of Retry packets. A client MUST discard a Retry -packet with a zero-length Retry Token field. +diminishes an attacker's ability to inject a Retry packet and protects against +accidental corruption of Retry packets. A client MUST discard a Retry packet +with a zero-length Retry Token field. The client responds to a Retry packet with an Initial packet that includes the provided Retry Token to continue connection establishment. From 4f837ca0145b7c7cd01a47190a5b12e5d8887238 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 23 Dec 2020 10:53:44 +1100 Subject: [PATCH 3/9] Consistency in use of off-path: -tls --- draft-ietf-quic-tls.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 43ed620134..5b9248f2c7 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -893,8 +893,8 @@ QUIC packets have varying protections depending on their type: * Version Negotiation packets have no cryptographic protection. * Retry packets use AEAD_AES_128_GCM to provide protection against accidental - modification or insertion by off-path adversaries; see - {{retry-integrity}}. + modification and to limit the entities that can produce a valid Retry; + see {{retry-integrity}}. * Initial packets use AEAD_AES_128_GCM with keys derived from the Destination Connection ID field of the first Initial packet sent by the client; see @@ -1386,8 +1386,8 @@ incoming 1-RTT protected packets before the TLS handshake is complete. Retry packets (see the Retry Packet section of {{QUIC-TRANSPORT}}) carry a Retry Integrity Tag that provides two properties: it allows discarding -packets that have accidentally been corrupted by the network, and it diminishes -off-path attackers' ability to send valid Retry packets. +packets that have accidentally been corrupted by the network; and only an +entity that receives an Initial packet is able to send a valid Retry packet. The Retry Integrity Tag is a 128-bit field that is computed as the output of AEAD_AES_128_GCM ({{!AEAD}}) used with the following inputs: @@ -1435,7 +1435,8 @@ Original Destination Connection ID: : The Original Destination Connection ID contains the value of the Destination Connection ID from the Initial packet that this Retry is in response to. The length of this field is given in ODCID Length. The presence of this field - mitigates an off-path attacker's ability to inject a Retry packet. + ensures that a valid Retry packet can only be sent by an entity that + receives the Initial packet. # Key Update From 9504a9fab1d12a599738996cf8ba9c0cda6d9d9e Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 23 Dec 2020 10:59:02 +1100 Subject: [PATCH 4/9] nits Co-authored-by: Jana Iyengar --- draft-ietf-quic-tls.md | 4 ++-- draft-ietf-quic-transport.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 5b9248f2c7..d9c7c55486 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1386,8 +1386,8 @@ incoming 1-RTT protected packets before the TLS handshake is complete. Retry packets (see the Retry Packet section of {{QUIC-TRANSPORT}}) carry a Retry Integrity Tag that provides two properties: it allows discarding -packets that have accidentally been corrupted by the network; and only an -entity that receives an Initial packet is able to send a valid Retry packet. +packets that have accidentally been corrupted by the network; only an +entity that receives an Initial packet can send a valid Retry packet. The Retry Integrity Tag is a 128-bit field that is computed as the output of AEAD_AES_128_GCM ({{!AEAD}}) used with the following inputs: diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index fd838c8b7d..ad294f3a58 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4258,7 +4258,7 @@ Path Maximum Transmission Unit Discovery (PMTUD; {{!RFC1191}}, {{!RFC8201}}) relies on reception of ICMP messages (e.g., IPv6 Packet Too Big messages) that indicate when an IP packet is dropped because it is larger than the local router MTU. DPLPMTUD can also optionally use these messages. This use of ICMP messages -is potentially vulnerable to attacks by elements that cannot observe packets, +is potentially vulnerable to attacks by elements that cannot observe packets but might successfully guess the addresses used on the path. These attacks could reduce the PMTU to a bandwidth-inefficient value. From 232fbb372e53e924dc3df7a8a55fc672cfdce041 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 23 Dec 2020 14:06:30 +1100 Subject: [PATCH 5/9] a good observation Co-authored-by: martinduke --- draft-ietf-quic-tls.md | 4 ++-- draft-ietf-quic-transport.md | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index d9c7c55486..a8815ec19a 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1387,7 +1387,7 @@ incoming 1-RTT protected packets before the TLS handshake is complete. Retry packets (see the Retry Packet section of {{QUIC-TRANSPORT}}) carry a Retry Integrity Tag that provides two properties: it allows discarding packets that have accidentally been corrupted by the network; only an -entity that receives an Initial packet can send a valid Retry packet. +entity that observes an Initial packet can send a valid Retry packet. The Retry Integrity Tag is a 128-bit field that is computed as the output of AEAD_AES_128_GCM ({{!AEAD}}) used with the following inputs: @@ -1436,7 +1436,7 @@ Original Destination Connection ID: Connection ID from the Initial packet that this Retry is in response to. The length of this field is given in ODCID Length. The presence of this field ensures that a valid Retry packet can only be sent by an entity that - receives the Initial packet. + observes the Initial packet. # Key Update diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index ad294f3a58..4d47b0db8a 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4650,7 +4650,7 @@ Connection ID MUST be copied from the Destination Connection ID of the received packet, which is initially randomly selected by a client. Echoing both connection IDs gives clients some assurance that the server received the packet and that the Version Negotiation packet was not generated by an entity that -did not receive the Initial packet. +did not observe the Initial packet. Future versions of QUIC could have different requirements for the lengths of connection IDs. In particular, connection IDs might have a smaller minimum @@ -4727,8 +4727,8 @@ Packet Payload: In order to prevent tampering by version-unaware middleboxes, Initial packets are protected with connection- and version-specific keys (Initial keys) as described in {{QUIC-TLS}}. This protection does not provide confidentiality or -integrity against on-path attackers, but provides some level of protection -against attackers that cannot also receive packets. +integrity against attackers that can observe packets, but provides some level of protection +against attackers that cannot also observes packets. The client and server use the Initial packet type for any packet that contains an initial cryptographic handshake message. This includes all cases where a new From 4b8f06ecbbdcfefea4b6441c71e984cd8f210c6b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 23 Dec 2020 14:06:56 +1100 Subject: [PATCH 6/9] Wrap --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 4d47b0db8a..a59810643c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4727,8 +4727,8 @@ Packet Payload: In order to prevent tampering by version-unaware middleboxes, Initial packets are protected with connection- and version-specific keys (Initial keys) as described in {{QUIC-TLS}}. This protection does not provide confidentiality or -integrity against attackers that can observe packets, but provides some level of protection -against attackers that cannot also observes packets. +integrity against attackers that can observe packets, but provides some level of +protection against attackers that cannot also observes packets. The client and server use the Initial packet type for any packet that contains an initial cryptographic handshake message. This includes all cases where a new From be3b4e852050338bea18bd61efe825f6b192d259 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 4 Jan 2021 09:54:31 +1100 Subject: [PATCH 7/9] Fewer words Co-authored-by: Mike Bishop --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index a59810643c..24bb74c9b5 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4728,7 +4728,7 @@ In order to prevent tampering by version-unaware middleboxes, Initial packets are protected with connection- and version-specific keys (Initial keys) as described in {{QUIC-TLS}}. This protection does not provide confidentiality or integrity against attackers that can observe packets, but provides some level of -protection against attackers that cannot also observes packets. +protection against attackers that cannot observe packets. The client and server use the Initial packet type for any packet that contains an initial cryptographic handshake message. This includes all cases where a new @@ -6719,7 +6719,7 @@ and inject those copies into the network, potentially with spoofed source and destination addresses. For the purposes of this discussion, it is assumed that an off-path attacker -has the ability to observe and re-inject a modified copy of a packet into the +has the ability to inject a modified copy of a packet into the network that will reach the destination endpoint prior to the arrival of the original packet observed by the attacker. In other words, an attacker has the ability to consistently "win" a race with the legitimate packets between the From b7b06086078b65ee99c456ad97643bb87146d9c1 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 4 Jan 2021 10:15:02 +1100 Subject: [PATCH 8/9] Add invariants to the list --- draft-ietf-quic-invariants.md | 6 +++--- draft-ietf-quic-transport.md | 13 ++++++------- 2 files changed, 9 insertions(+), 10 deletions(-) diff --git a/draft-ietf-quic-invariants.md b/draft-ietf-quic-invariants.md index 0d723feaea..c17f914fc6 100644 --- a/draft-ietf-quic-invariants.md +++ b/draft-ietf-quic-invariants.md @@ -316,8 +316,8 @@ packet it receives in the Destination Connection ID field. The value for Source Connection ID MUST be copied from the Destination Connection ID of the received packet, which is initially randomly selected by a client. Echoing both connection IDs gives clients some assurance that the server received the packet -and that the Version Negotiation packet was not generated by an off-path -attacker. +and that the Version Negotiation packet was not generated by an attacker that is +unable to observe packets. An endpoint that receives a Version Negotiation packet might change the version that it decides to use for subsequent packets. The conditions under which an @@ -343,7 +343,7 @@ reliably extracting information from a flow based on version-specific traits requires that middleboxes retain state for every connection ID they see. The Version Negotiation packet described in this document is not -integrity-protected; it only has modest protection against insertion by off-path +integrity-protected; it only has modest protection against insertion by attackers. An endpoint MUST authenticate the contents of a Version Negotiation packet if it attempts a different QUIC version as a result. diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 24bb74c9b5..19ff11e0a4 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -6718,13 +6718,12 @@ An off-path attacker can create modified copies of packets that it has observed and inject those copies into the network, potentially with spoofed source and destination addresses. -For the purposes of this discussion, it is assumed that an off-path attacker -has the ability to inject a modified copy of a packet into the -network that will reach the destination endpoint prior to the arrival of the -original packet observed by the attacker. In other words, an attacker has the -ability to consistently "win" a race with the legitimate packets between the -endpoints, potentially causing the original packet to be ignored by the -recipient. +For the purposes of this discussion, it is assumed that an off-path attacker has +the ability to inject a modified copy of a packet into the network that will +reach the destination endpoint prior to the arrival of the original packet +observed by the attacker. In other words, an attacker has the ability to +consistently "win" a race with the legitimate packets between the endpoints, +potentially causing the original packet to be ignored by the recipient. It is also assumed that an attacker has the resources necessary to affect NAT state, potentially both causing an endpoint to lose its NAT binding, and an From 6d5f25cf8498c2318b3ef62971cac2cf56505ef0 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 5 Jan 2021 14:23:41 +1100 Subject: [PATCH 9/9] entities --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 19ff11e0a4..94415885e2 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4258,7 +4258,7 @@ Path Maximum Transmission Unit Discovery (PMTUD; {{!RFC1191}}, {{!RFC8201}}) relies on reception of ICMP messages (e.g., IPv6 Packet Too Big messages) that indicate when an IP packet is dropped because it is larger than the local router MTU. DPLPMTUD can also optionally use these messages. This use of ICMP messages -is potentially vulnerable to attacks by elements that cannot observe packets +is potentially vulnerable to attacks by entities that cannot observe packets but might successfully guess the addresses used on the path. These attacks could reduce the PMTU to a bandwidth-inefficient value.