From f125a502689429e69d4a52f4ed9c9c18b185b06f Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 10 May 2018 15:39:04 +1000 Subject: [PATCH 1/3] Write down spoofed packet guarantees We agreed to this a while back, but never got around to putting the conclusions in the document. We've done some of the work by writing down the rules for use of CONNECTION_CLOSE and TLS alerts, and the related changes, but the basic principles never got articulated. This attempts to outline what we do to authenticate packets that we receive. * Once the handshake is done, it's mostly simple: if the AEAD fails, drop it. * We have a small carve-out for some types of ICMP, with some strong limitations on what that information can be used for. @igorlord might expand the PMTU usage to cover DestUnreach, but these uses permit a very narrow range of actions. * We also have stateless reset, which is another snowflake. * The bulk of the text here concerns the handshake. I've covered the two mechanisms we tie into the use of connection IDs: ** Echoing the value (the only protection we have for Version Negotiation, for instance). ** The AEAD that uses the connection ID as input. And then it explains that our only defense against an on-path attacker is to fail to establish a connection. I think that covers all the necessary points. Closes #645. --- draft-ietf-quic-transport.md | 51 +++++++++++++++++++++++++++++++++++- 1 file changed, 50 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c5c75180c6..7d08bd603b 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3150,7 +3150,7 @@ QUIC packets on the affected path. This could result in termination of the connection if an alternative path cannot be found. -### Special Considerations for PMTU Discovery +### IPv4 PMTU Discovery {#v4-pmtud} Traditional ICMP-based path MTU discovery in IPv4 {{!PMTUDv4}} is potentially vulnerable to off-path attacks that successfully guess the IP/port 4-tuple and @@ -4017,6 +4017,55 @@ transport to cancel a stream in response to receipt of a STOP_SENDING frame. # Security Considerations +## Handshake Denial of Service + +As an encrypted and authenticated transport QUIC provides a range of protections +against denial of service. Once the cryptographic handshake is complete, QUIC +endpoints discard packets that are not authenticated, greatly limiting the +ability of an attacker to interfere with existing connections. + +Once a connection is established QUIC endpoints might accept some +unauthenticated ICMP packets (see {{v4-pmtud}}), but the use of these packets is +extremely limited. The only other type of packet that an endpoint might accept +is a stateless reset ({{stateless-reset}}) which relies on the token being kept +secret until it is used. + +During the creation of a connection, QUIC only provides protection against +attack from off the network path. All QUIC packets contain proof that the +recipient saw a preceding packet from its peer. + +The first mechanism used is the source and destination connection IDs, which are +required to match those set by a peer. Except for an Initial packet and +stateless reset, an endpoint only accepts packets that include a destination +connection that matches a connection ID the endpoint previously chose. This is +the only protection offered for Version Negotiation packets. + +The destination connection ID in an Initial packet is selected by a client to be +unpredictable, which serves an additional purpose. The packets that carry the +cryptographic handshake are protected with a key that is derived from the +connection ID and salt specific to the QUIC version. This allows endpoints to +use the same process for authenticating packets that they receive as they use +after the cryptographic handshake completes. Packets that cannot be +authenticated are discarded. Protecting packets in this fashion provides a +strong assurance that the sender of the packet saw previous packets and +understood them. + +These protections are not intended to be effective against an attacker that is +able to receive QUIC packets. Such an attacker can potentially send packets +that will be accepted by QUIC clients or servers. This version of QUIC only +attempts to detect this sort of attack. Interference with the handshake is +detected when the cryptographic handshake fails. For the most part, this is a +property that the cryptographic handshake protocol {{QUIC-TLS}} is required to +provide, though additional validation is required for version negotiation (see +{{version-validation}}). + +Endpoints are permitted to use other methods to detect and attempt to recover +from interference with the handshake. For instance, if invalid packets can be +identified then they can be discarded. This can be complex or difficult and so +no specific method is mandated in this version of QUIC. + + + ## Spoofed ACK Attack An attacker might be able to receive an address validation token From 6cc16b637b240efc6bb6674a523dd7d599aaab0e Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 23 May 2018 17:12:55 +1000 Subject: [PATCH 2/3] Addressing review comments, rewording handshakey bit --- draft-ietf-quic-transport.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 7d08bd603b..16ea876ab5 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4021,7 +4021,7 @@ transport to cancel a stream in response to receipt of a STOP_SENDING frame. As an encrypted and authenticated transport QUIC provides a range of protections against denial of service. Once the cryptographic handshake is complete, QUIC -endpoints discard packets that are not authenticated, greatly limiting the +endpoints discard most packets that are not authenticated, greatly limiting the ability of an attacker to interfere with existing connections. Once a connection is established QUIC endpoints might accept some @@ -4035,35 +4035,35 @@ attack from off the network path. All QUIC packets contain proof that the recipient saw a preceding packet from its peer. The first mechanism used is the source and destination connection IDs, which are -required to match those set by a peer. Except for an Initial packet and -stateless reset, an endpoint only accepts packets that include a destination +required to match those set by a peer. Except for an Initial and stateless +reset packets, an endpoint only accepts packets that include a destination connection that matches a connection ID the endpoint previously chose. This is the only protection offered for Version Negotiation packets. The destination connection ID in an Initial packet is selected by a client to be unpredictable, which serves an additional purpose. The packets that carry the -cryptographic handshake are protected with a key that is derived from the +cryptographic handshake are protected with a key that is derived from this connection ID and salt specific to the QUIC version. This allows endpoints to use the same process for authenticating packets that they receive as they use after the cryptographic handshake completes. Packets that cannot be authenticated are discarded. Protecting packets in this fashion provides a -strong assurance that the sender of the packet saw previous packets and -understood them. +strong assurance that the sender of the packet saw the Initial packets and +understood it. These protections are not intended to be effective against an attacker that is -able to receive QUIC packets. Such an attacker can potentially send packets -that will be accepted by QUIC clients or servers. This version of QUIC only -attempts to detect this sort of attack. Interference with the handshake is -detected when the cryptographic handshake fails. For the most part, this is a -property that the cryptographic handshake protocol {{QUIC-TLS}} is required to -provide, though additional validation is required for version negotiation (see +able to receive QUIC packets prior to the connection being established. Such an +attacker can potentially send packets that will be accepted by QUIC clients or +servers. This version of QUIC attempts to detect this sort of attack, but it +expects that endpoints will fail to establish a connection rather than +recovering. For the most part, the cryptographic handshake protocol +{{QUIC-TLS}} is responsible for detecting tampering during the handshake, though +additional validation is required for version negotiation (see {{version-validation}}). Endpoints are permitted to use other methods to detect and attempt to recover -from interference with the handshake. For instance, if invalid packets can be -identified then they can be discarded. This can be complex or difficult and so -no specific method is mandated in this version of QUIC. - +from interference with the handshake. Invalid packets may be identified and +discarded using other methods, but no specific method is mandated in this +document. ## Spoofed ACK Attack From 47222869b758e499c4cca5ec24e5ccd395e5120f Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 24 May 2018 11:13:28 +1000 Subject: [PATCH 3/3] Fix plurals --- draft-ietf-quic-transport.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 16ea876ab5..3145a17f69 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4047,18 +4047,17 @@ connection ID and salt specific to the QUIC version. This allows endpoints to use the same process for authenticating packets that they receive as they use after the cryptographic handshake completes. Packets that cannot be authenticated are discarded. Protecting packets in this fashion provides a -strong assurance that the sender of the packet saw the Initial packets and +strong assurance that the sender of the packet saw the Initial packet and understood it. These protections are not intended to be effective against an attacker that is able to receive QUIC packets prior to the connection being established. Such an -attacker can potentially send packets that will be accepted by QUIC clients or -servers. This version of QUIC attempts to detect this sort of attack, but it -expects that endpoints will fail to establish a connection rather than -recovering. For the most part, the cryptographic handshake protocol -{{QUIC-TLS}} is responsible for detecting tampering during the handshake, though -additional validation is required for version negotiation (see -{{version-validation}}). +attacker can potentially send packets that will be accepted by QUIC endpoints. +This version of QUIC attempts to detect this sort of attack, but it expects that +endpoints will fail to establish a connection rather than recovering. For the +most part, the cryptographic handshake protocol {{QUIC-TLS}} is responsible for +detecting tampering during the handshake, though additional validation is +required for version negotiation (see {{version-validation}}). Endpoints are permitted to use other methods to detect and attempt to recover from interference with the handshake. Invalid packets may be identified and