Datagram 1200

draft-ietf-quic-tls.md

@@ -514,22 +514,31 @@ 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 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.
+
+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
+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

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