Subject: [quicwg/base-drafts] Datagram 1200 (#1548)

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jul 2018 22:20:01 -0700

This fixes inconsistencies throughout in our treatment of the 1200 octet limit.

I also took another tilt at the ClientHello limitations section, which hadn't taken the addition of the token into account.  I don't explicitly calculate a limit, but I do mention the size of the minimal overheads, and mention other ways in which the limit might be reduced.

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

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

-- Commit Summary --

  * Fix 1200 octet Datagram vs. Packet inconsistencies
  * Rewrite section on ClientHello size

-- File Changes --

    M draft-ietf-quic-tls.md (39)
    M draft-ietf-quic-transport.md (30)

-- Patch Links --

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 10 Jul 2018 23:11:17 -0700

MikeBishop commented on this pull request.

Largely editorial nits.

> -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

**a** connection ID with non-zero length, perhaps?

> -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.

longer than octets?

> -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

You say below that HelloRetryRequest-triggered ClientHellos are exempt from this restriction, so it might be less confusing to omit that from your list of examples.

> +
+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

Same.

> -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

Given that 1200 is a minimum, not a maximum, it might be worth calling out that the datagram can be larger than 1200 if needed.

> +
+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.

Consistency nits:
- You use "a" before other TLS handshake messages, so "**a** HelloRetryRequest"
- You use "fit into" elsewhere, but "fit ... in" here.

-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

Since we're still talking about "the first Initial packet [the client] sends," perhaps "the first" or "this" instead of "an"?

 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

...but only if it's the first Initial packet on the connection, right?

-- 
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/1548#pullrequestreview-136099506

---

From: MikkelFJ <[email-masked]>
Date: Tue, 10 Jul 2018 23:31:02 -0700

mikkelfj commented on this pull request.

A QUIC packet can hardly fit into more than a single UDP datagram, so perhaps be clear that the TLS message must fit within the first Initial QUIC packet. - if that is the intention.

-- 
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/1548#discussion_r201576142

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jul 2018 23:36:52 -0700

@martinthomson pushed 1 commit.

7c6392d  1200 isn't an actual limit; consistency

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1548/files/377867695418798f13b337602b631106a1c226ff..7c6392de9ae2f27760eabf7c00a671424fe118d9

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jul 2018 23:38:38 -0700

dd98adc  The first Initial packet is the only special one

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1548/files/7c6392de9ae2f27760eabf7c00a671424fe118d9..dd98adccef7b402ecada7852dac14a3d2b1e518a

---

From: MikkelFJ <[email-masked]>
Date: Tue, 10 Jul 2018 23:59:22 -0700

@martinthomson not sure you saw my comment since you just made and update to that section that didn't address it, or perhaps you disagree, but:

> QUIC requires that the first Initial packet from a client be sent in a single
  UDP datagram.

This sentence doesn't make sense to me because all QUIC packets are necessarily placed in a UDP single datagram. The intention is of course the the initial client hello TLS message must fit within the QUIC initial packet.

-- 
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/1548#issuecomment-404065667

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jul 2018 23:59:34 -0700

3e740f4  Tweaking more

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1548/files/dd98adccef7b402ecada7852dac14a3d2b1e518a..3e740f4e5433d23f2d28f7f82b2914011ca49cad

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jul 2018 00:01:13 -0700

@mikkelfj, email got through, and I've pushed an update that should help.

-- 
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/1548#issuecomment-404066087

---

From: Nick Banks <[email-masked]>
Date: Wed, 11 Jul 2018 06:23:43 -0700

nibanks approved this pull request.

Looks good. One minor nit.

> @@ -3629,19 +3629,24 @@ 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

`MUST pad ensure that`? Should `pad` be removed here?

-- 
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/1548#pullrequestreview-136234865

---

From: ianswett <[email-masked]>
Date: Wed, 11 Jul 2018 06:51:08 -0700

ianswett commented on this pull request.

-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 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

I think the first "overheads" is unnecessary and the second can be "overhead"

-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 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
+ID without zero length, nor does it include the token or a connection ID longer

nor does it -> and does not

-
-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 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
+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.

This sentence is long, maybe a comma after "octets"

> +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.
+
+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 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 the ClientHello that it sends in response to a

Is this because HRR is assumed to be stateful?

MUST pad to ensure?

-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

How about: "Padding the Initial packet or including a 0-RTT packet in the same datagram are ways to meet this requirement."  Feel free to add good if you want, but that seems unnecessary.

-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)

knows -> believes

-- 
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/1548#pullrequestreview-136243347

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jul 2018 16:58:28 -0700

36cabe6  I need to work on my proofreading

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1548/files/3e740f4e5433d23f2d28f7f82b2914011ca49cad..36cabe6fb2cb4e88126e2899d1e2f92b46cee85a

---

From: Christian Huitema <[email-masked]>
Date: Thu, 12 Jul 2018 17:03:07 -0700

huitema commented on this pull request.

> @@ -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.

1200 octets of *UDP* payload?

I know this is implicit, but we also use payload to refer to the part of a QUIC packet that follows the header.

-- 
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/1548#pullrequestreview-136870052

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Jul 2018 21:07:57 -0700

d2a655d  UDP payload

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1548/files/36cabe6fb2cb4e88126e2899d1e2f92b46cee85a..d2a655d17418077c483a19eabd520b61868e38f8

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Jul 2018 21:18:30 -0700

Merged #1548.

-- 
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/1548#event-1759259964