From 3504e23386d3042de66e3963b66309d2eb6a2377 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 11 Jul 2018 14:51:53 +1000 Subject: [PATCH 1/7] Fix 1200 octet Datagram vs. Packet inconsistencies Closes #1546. --- draft-ietf-quic-transport.md | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index bf76dae3e3..36987d77bf 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1775,9 +1775,9 @@ use the server to send more data toward the victim than it would be able to send on its own. Several methods are used in QUIC to mitigate this attack. Firstly, the initial -handshake packet is padded to at least 1200 octets. This allows a server to -send a similar amount of data without risking causing an amplification attack -toward an unproven remote address. +handshake packet is sent in a UDP datagram that contains at least 1200 octets of +payload. This allows a server to send a similar amount of data without risking +causing an amplification attack toward an unproven remote address. A server eventually confirms that a client has received its messages when the first Handshake-level message is received. This might be insufficient, @@ -3629,19 +3629,23 @@ The details of loss detection and congestion control are described in The QUIC packet size includes the QUIC header and integrity check, but not the UDP or IP header. -Clients MUST pad any Initial packet it sends to have a QUIC packet size of at -least 1200 octets. Sending an Initial packet of this size ensures that the -network path supports a reasonably sized packet, and helps reduce the amplitude -of amplification attacks caused by server responses toward an unverified client -address. +Clients MUST pad ensure that the first Initial packet it sends is sent in a UDP +datagram that is at least 1200 octets. Padding the Initial packet is a good way +to ensure this, though including a 0-RTT packet in the same datagram is also a +good way to meet this requirement. Sending a UDP datagram of this size ensures +that the network path supports a reasonable Maximum Transmission Unit (MTU), and +helps reduce the amplitude of amplification attacks caused by server responses +toward an unverified client address. -An Initial packet MAY exceed 1200 octets if the client knows that the Path -Maximum Transmission Unit (PMTU) supports the size that it chooses. +The datagram containing an Initial packet MAY exceed 1200 octets if the client +knows that the Path Maximum Transmission Unit (PMTU) supports the size that it +chooses. A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in -response to an Initial packet smaller than 1200 octets. It MUST NOT send any -other frame type in response, or otherwise behave as if any part of the -offending packet was processed as valid. +response to an Initial packet contained in a UDP datagram that is smaller than +1200 octets. It MUST NOT send any other frame type in response, or otherwise +behave as if any part of the offending packet was processed as valid. + ## Path Maximum Transmission Unit From 377867695418798f13b337602b631106a1c226ff Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 11 Jul 2018 15:12:20 +1000 Subject: [PATCH 2/7] Rewrite section on ClientHello size --- draft-ietf-quic-tls.md | 39 +++++++++++++++++++++++---------------- 1 file changed, 23 insertions(+), 16 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 7c94b6a522..209ac16c03 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -514,22 +514,29 @@ older than 1.3 is negotiated. ## ClientHello Size {#clienthello-size} -QUIC requires that the initial handshake packet from a client fit within the -payload of a single packet. The size limits on QUIC packets mean that a record -containing a ClientHello needs to fit within 1129 octets, though endpoints can -reduce the size of their connection ID to increase by up to 22 octets. - -A TLS ClientHello can fit within this limit with ample space remaining. -However, there are several variables that could cause this limit to be exceeded. -Implementations are reminded that large session tickets or HelloRetryRequest -cookies, multiple or large key shares, and long lists of supported ciphers, -signature algorithms, versions, QUIC transport parameters, and other negotiable -parameters and extensions could cause this message to grow. - -For servers, the size of the session tickets and HelloRetryRequest cookie -extension can have an effect on a client's ability to connect. Choosing a small -value increases the probability that these values can be successfully used by a -client. +QUIC requires that the first Initial packet from a client be sent in a single +UDP datagram. This places constraints on the first ClientHello message. + +QUIC packet and framing overheads add at least 36 octets of overheads to the +ClientHello message. That overhead increases if the client chooses connection +ID without zero length, nor does it include the token or a connection ID longer +than octets that might be required if a server sends a Retry packet. + +With these overheads, a typical TLS ClientHello can fit into a 1200 octet packet +with ample space remaining. However, aside from the overheads added by QUIC, +there are several variables that could cause this limit to be exceeded. Large +session tickets or HelloRetryRequest cookies, multiple or large key shares, and +long lists of supported ciphers, signature algorithms, versions, QUIC transport +parameters, and other negotiable parameters and extensions could cause this +message to grow. + +For servers, in addition to connection ID and tokens, the size of TLS session +tickets and HelloRetryRequest cookie extensions can have an effect on a client's +ability to connect. Choosing a small value increases the probability that these +values can be successfully used by a client. + +A client is not required to fit a ClientHello that is sent in response to +HelloRetryRequest in a single UDP datagram. The TLS implementation does not need to ensure that the ClientHello is sufficiently large. QUIC PADDING frames are added to increase the size of the From 7c6392de9ae2f27760eabf7c00a671424fe118d9 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 11 Jul 2018 16:32:12 +1000 Subject: [PATCH 3/7] 1200 isn't an actual limit; consistency --- draft-ietf-quic-tls.md | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 209ac16c03..e349c1e1e8 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -515,28 +515,29 @@ older than 1.3 is negotiated. ## ClientHello Size {#clienthello-size} QUIC requires that the first Initial packet from a client be sent in a single -UDP datagram. This places constraints on the first ClientHello message. +UDP datagram. Though a packet larger than 1200 octets might be supported by the +path, a client improves the likelihood that a packet is accepted if it ensures +that the first ClientHello message it sends remains within this limit. QUIC packet and framing overheads add at least 36 octets of overheads to the -ClientHello message. That overhead increases if the client chooses connection +ClientHello message. That overhead increases if the client chooses a connection ID without zero length, nor does it include the token or a connection ID longer -than octets that might be required if a server sends a Retry packet. +than 8 octets that might be required if a server sends a Retry packet. -With these overheads, a typical TLS ClientHello can fit into a 1200 octet packet -with ample space remaining. However, aside from the overheads added by QUIC, -there are several variables that could cause this limit to be exceeded. Large -session tickets or HelloRetryRequest cookies, multiple or large key shares, and -long lists of supported ciphers, signature algorithms, versions, QUIC transport -parameters, and other negotiable parameters and extensions could cause this -message to grow. +A typical TLS ClientHello can easily fit into a 1200 octet packet. However, in +addition to the overheads added by QUIC, there are several variables that could +cause this limit to be exceeded. Large session tickets, multiple or large key +shares, and long lists of supported ciphers, signature algorithms, versions, +QUIC transport parameters, and other negotiable parameters and extensions could +cause this message to grow. For servers, in addition to connection ID and tokens, the size of TLS session -tickets and HelloRetryRequest cookie extensions can have an effect on a client's -ability to connect. Choosing a small value increases the probability that these -values can be successfully used by a client. +tickets can have an effect on a client's ability to connect. Minimizing the +size of these values increases the probability that they can be successfully +used by a client. -A client is not required to fit a ClientHello that is sent in response to -HelloRetryRequest in a single UDP datagram. +A client is not required to fit the ClientHello that it sends in response to a +HelloRetryRequest message into a single UDP datagram. The TLS implementation does not need to ensure that the ClientHello is sufficiently large. QUIC PADDING frames are added to increase the size of the From dd98adccef7b402ecada7852dac14a3d2b1e518a Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 11 Jul 2018 16:33:58 +1000 Subject: [PATCH 4/7] The first Initial packet is the only special one --- draft-ietf-quic-transport.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 36987d77bf..80c469ce15 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3637,14 +3637,15 @@ that the network path supports a reasonable Maximum Transmission Unit (MTU), and helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address. -The datagram containing an Initial packet MAY exceed 1200 octets if the client -knows that the Path Maximum Transmission Unit (PMTU) supports the size that it -chooses. +The datagram containing the first Initial packet from a client MAY exceed 1200 +octets if the client knows that the Path Maximum Transmission Unit (PMTU) +supports the size that it chooses. A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in -response to an Initial packet contained in a UDP datagram that is smaller than -1200 octets. It MUST NOT send any other frame type in response, or otherwise -behave as if any part of the offending packet was processed as valid. +response to the first Initial packet it receives from a client if the UDP +datagram is smaller than 1200 octets. It MUST NOT send any other frame type in +response, or otherwise behave as if any part of the offending packet was +processed as valid. ## Path Maximum Transmission Unit From 3e740f4e5433d23f2d28f7f82b2914011ca49cad Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 11 Jul 2018 16:54:56 +1000 Subject: [PATCH 5/7] Tweaking more --- draft-ietf-quic-tls.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index e349c1e1e8..44633b81ad 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -514,10 +514,11 @@ older than 1.3 is negotiated. ## ClientHello Size {#clienthello-size} -QUIC requires that the first Initial packet from a client be sent in a single -UDP datagram. Though a packet larger than 1200 octets might be supported by the -path, a client improves the likelihood that a packet is accepted if it ensures -that the first ClientHello message it sends remains within this limit. +QUIC requires that the first Initial packet from a client contain an entire +crytographic handshake message, which for TLS is the ClientHello. Though a +packet larger than 1200 octets might be supported by the path, a client improves +the likelihood that a packet is accepted if it ensures that the first +ClientHello message is small enough to stay within this limit. QUIC packet and framing overheads add at least 36 octets of overheads to the ClientHello message. That overhead increases if the client chooses a connection From 36cabe6fb2cb4e88126e2899d1e2f92b46cee85a Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 12 Jul 2018 09:53:44 +1000 Subject: [PATCH 6/7] I need to work on my proofreading --- draft-ietf-quic-tls.md | 8 ++++---- draft-ietf-quic-transport.md | 15 +++++++-------- 2 files changed, 11 insertions(+), 12 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 44633b81ad..abcda1d6b3 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -520,10 +520,10 @@ packet larger than 1200 octets might be supported by the path, a client improves the likelihood that a packet is accepted if it ensures that the first ClientHello message is small enough to stay within this limit. -QUIC packet and framing overheads add at least 36 octets of overheads to the -ClientHello message. That overhead increases if the client chooses a connection -ID without zero length, nor does it include the token or a connection ID longer -than 8 octets that might be required if a server sends a Retry packet. +QUIC packet and framing add at least 36 octets of overhead to the ClientHello +message. That overhead increases if the client chooses a connection ID without +zero length. Overheads also do not include the token or a connection ID longer +than 8 octets, both of which might be required if a server sends a Retry packet. A typical TLS ClientHello can easily fit into a 1200 octet packet. However, in addition to the overheads added by QUIC, there are several variables that could diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 80c469ce15..020f4c85a7 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3629,16 +3629,15 @@ The details of loss detection and congestion control are described in The QUIC packet size includes the QUIC header and integrity check, but not the UDP or IP header. -Clients MUST pad ensure that the first Initial packet it sends is sent in a UDP -datagram that is at least 1200 octets. Padding the Initial packet is a good way -to ensure this, though including a 0-RTT packet in the same datagram is also a -good way to meet this requirement. Sending a UDP datagram of this size ensures -that the network path supports a reasonable Maximum Transmission Unit (MTU), and -helps reduce the amplitude of amplification attacks caused by server responses -toward an unverified client address. +Clients MUST ensure that the first Initial packet it sends is sent in a UDP +datagram that is at least 1200 octets. Padding the Initial packet or including a +0-RTT packet in the same datagram are ways to meet this requirement. Sending a +UDP datagram of this size ensures that the network path supports a reasonable +Maximum Transmission Unit (MTU), and helps reduce the amplitude of amplification +attacks caused by server responses toward an unverified client address. The datagram containing the first Initial packet from a client MAY exceed 1200 -octets if the client knows that the Path Maximum Transmission Unit (PMTU) +octets if the client believes that the Path Maximum Transmission Unit (PMTU) supports the size that it chooses. A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in From d2a655d17418077c483a19eabd520b61868e38f8 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 30 Jul 2018 14:03:37 +1000 Subject: [PATCH 7/7] UDP payload --- 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 020f4c85a7..8cfac0f8e9 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1776,8 +1776,8 @@ on its own. Several methods are used in QUIC to mitigate this attack. Firstly, the initial handshake packet is sent in a UDP datagram that contains at least 1200 octets of -payload. This allows a server to send a similar amount of data without risking -causing an amplification attack toward an unproven remote address. +UDP payload. This allows a server to send a similar amount of data without +risking causing an amplification attack toward an unproven remote address. A server eventually confirms that a client has received its messages when the first Handshake-level message is received. This might be insufficient,