diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 6af2a3088d..2db258bc19 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -1002,15 +1002,15 @@ previously received MUST be treated as a connection error of type H3_ID_ERROR; see {{errors}}. An endpoint that is attempting to gracefully shut down a connection can send a -GOAWAY frame with a value set to the maximum possible value (2^62-4 for servers, -2^62-1 for clients). This ensures that the peer stops creating new requests or -pushes. After allowing time for any in-flight requests or pushes to arrive, the -endpoint can send another GOAWAY frame indicating which requests or pushes it -might accept before the end of the connection. This ensures that a connection -can be cleanly shut down without losing requests. +GOAWAY frame with a value set to the maximum possible value (262-4 +for servers, 262-1 for clients). This ensures that the peer stops +creating new requests or pushes. After allowing time for any in-flight requests +or pushes to arrive, the endpoint can send another GOAWAY frame indicating which +requests or pushes it might accept before the end of the connection. This +ensures that a connection can be cleanly shut down without losing requests. A client has more flexibility in the value it chooses for the Push ID in a -GOAWAY that it sends. A value of 2^62 - 1 indicates that the server can +GOAWAY that it sends. A value of 262-1 indicates that the server can continue fulfilling pushes that have already been promised. A smaller value indicates the client will reject pushes with Push IDs greater than or equal to this value. Like the server, the client MAY send subsequent GOAWAY frames so @@ -2280,10 +2280,11 @@ Some important departures are noted in this section. ## Streams {#h2-streams} -HTTP/3 permits use of a larger number of streams (2^62-1) than HTTP/2. The same -considerations about exhaustion of stream identifier space apply, though the -space is significantly larger such that it is likely that other limits in QUIC -are reached first, such as the limit on the connection flow control window. +HTTP/3 permits use of a larger number of streams (262-1) than HTTP/2. +The same considerations about exhaustion of stream identifier space apply, +though the space is significantly larger such that it is likely that other +limits in QUIC are reached first, such as the limit on the connection flow +control window. In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by QUIC. QUIC considers a stream closed when all data has been received and sent data has been diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index aad5c6c02d..a290c92459 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1731,12 +1731,13 @@ It is RECOMMENDED that endpoints immediately close the connection with a connection error of type AEAD_LIMIT_REACHED before reaching a state where key updates are not possible. -For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit is 2^23 -encrypted packets; see {{gcm-bounds}}. For AEAD_CHACHA20_POLY1305, the -confidentiality limit is greater than the number of possible packets (2^62) and -so can be disregarded. For AEAD_AES_128_CCM, the confidentiality limit is 2^21.5 -encrypted packets; see {{ccm-bounds}}. Applying a limit reduces the probability -that an attacker can distinguish the AEAD in use from a random permutation; see +For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit is +223 encrypted packets; see {{gcm-bounds}}. For +AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the number of +possible packets (262) and so can be disregarded. For +AEAD_AES_128_CCM, the confidentiality limit is 221.5 encrypted +packets; see {{ccm-bounds}}. Applying a limit reduces the probability that an +attacker can distinguish the AEAD in use from a random permutation; see {{AEBounds}}, {{ROBUST}}, and {{?GCM-MU=DOI.10.1145/3243734.3243816}}. In addition to counting packets sent, endpoints MUST count the number of @@ -1746,12 +1747,12 @@ connection, across all keys, exceeds the integrity limit for the selected AEAD, the endpoint MUST immediately close the connection with a connection error of type AEAD_LIMIT_REACHED and not process any more packets. -For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is 2^52 invalid -packets; see {{gcm-bounds}}. For AEAD_CHACHA20_POLY1305, the integrity limit is -2^36 invalid packets; see {{AEBounds}}. For AEAD_AES_128_CCM, the integrity -limit is 2^21.5 invalid packets; see {{ccm-bounds}}. Applying this limit reduces -the probability that an attacker can successfully forge a packet; see -{{AEBounds}}, {{ROBUST}}, and {{?GCM-MU}}. +For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is 252 +invalid packets; see {{gcm-bounds}}. For AEAD_CHACHA20_POLY1305, the integrity +limit is 236 invalid packets; see {{AEBounds}}. For AEAD_AES_128_CCM, +the integrity limit is 221.5 invalid packets; see +{{ccm-bounds}}. Applying this limit reduces the probability that an attacker can +successfully forge a packet; see {{AEBounds}}, {{ROBUST}}, and {{?GCM-MU}}. Endpoints that limit the size of packets MAY use higher confidentiality and integrity limits; see {{aead-analysis}} for details. @@ -2001,7 +2002,8 @@ header protection. Protecting two different headers with the same key and ciphertext sample reveals the exclusive OR of the protected fields. Assuming that the AEAD acts as a PRF, if L bits are sampled, the odds of two ciphertext samples being identical approach 2^(-L/2), that is, the birthday bound. For the -algorithms described in this document, that probability is one in 2^64. +algorithms described in this document, that probability is one in +264. To prevent an attacker from modifying packet headers, the header is transitively authenticated using packet protection; the entire packet header is part of the @@ -2401,23 +2403,24 @@ o: The analyses that follow rely on a count of the number of block operations involved in producing each message. This analysis is performed for packets of -size up to 2^11 (l = 2^7) and 2^16 (l = 2^12). A size of 2^11 is expected to be -a limit that matches common deployment patterns, whereas the 2^16 is the maximum -possible size of a QUIC packet. Only endpoints that strictly limit packet size -can use the larger confidentiality and integrity limits that are derived using -the smaller packet size. +size up to 211 (l = 27) and 216 (l = +212). A size of 211 is expected to be a limit that matches +common deployment patterns, whereas the 216 is the maximum possible +size of a QUIC packet. Only endpoints that strictly limit packet size can use +the larger confidentiality and integrity limits that are derived using the +smaller packet size. For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the message length (l) is the length of the associated data in blocks plus the length of the plaintext in blocks. -For AEAD_AES_128_CCM, the total number of block cipher operations is the sum -of: the length of the associated data in blocks, the length of the ciphertext -in blocks, the length of the plaintext in blocks, plus 1. In this analysis, -this is simplified to a value of twice the length of the packet in blocks (that -is, `2l = 2^8` for packets that are limited to 2^11 bytes, or `2l = 2^13` -otherwise). This simplification is based on the packet containing all of the -associated data and ciphertext. This results in a 1 to 3 block overestimation -of the number of operations per packet. +For AEAD_AES_128_CCM, the total number of block cipher operations is the sum of: +the length of the associated data in blocks, the length of the ciphertext in +blocks, the length of the plaintext in blocks, plus 1. In this analysis, this is +simplified to a value of twice the length of the packet in blocks (that is, +2l = 28 for packets that are limited to 211 +bytes, or 2l = 213 otherwise). This simplification is based +on the packet containing all of the associated data and ciphertext. This results +in a 1 to 3 block overestimation of the number of operations per packet. ## Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits {#gcm-bounds} @@ -2449,16 +2452,17 @@ attacker is: 2 * (q * l)^2 / 2^n ~~~ -For a target advantage of 2^-57, this results in the relation: +For a target advantage of 2-57, this results in the relation: ~~~ q <= 2^35 / l ~~~ -Thus, endpoints that do not send packets larger than 2^11 bytes cannot protect -more than 2^28 packets in a single connection without causing an attacker to -gain an larger advantage than the target of 2^-57. The limit for endpoints that -allow for the packet size to be as large as 2^16 is instead 2^23. +Thus, endpoints that do not send packets larger than 211 bytes cannot +protect more than 228 packets in a single connection without causing +an attacker to gain an larger advantage than the target of 2-57. The +limit for endpoints that allow for the packet size to be as large as +216 is instead 223. ### Integrity Limit @@ -2471,18 +2475,19 @@ an advantage in successfully forging a packet of no more than: + ((2 * o * v) / 2^(k + n)) + (n * (v + (v * l)) / 2^k) ~~~ -The goal is to limit this advantage to 2^-57. For AEAD_AES_128_GCM, the fourth -term in this inequality dominates the rest, so the others can be removed without -significant effect on the result. This produces the following approximation: +The goal is to limit this advantage to 2-57. For AEAD_AES_128_GCM, +the fourth term in this inequality dominates the rest, so the others can be +removed without significant effect on the result. This produces the following +approximation: ~~~ v <= 2^64 / l ~~~ -Endpoints that do not attempt to remove protection from packets larger than 2^11 -bytes can attempt to remove protection from at most 2^57 packets. Endpoints that -do not restrict the size of processed packets can attempt to remove protection -from at most 2^52 packets. +Endpoints that do not attempt to remove protection from packets larger than +211 bytes can attempt to remove protection from at most +257 packets. Endpoints that do not restrict the size of processed +packets can attempt to remove protection from at most 252 packets. For AEAD_AES_256_GCM, the same term dominates, but the larger value of k produces the following approximation: @@ -2532,16 +2537,16 @@ second, so that term can be removed without a significant effect on the result. This produces a relation that combines both encryption and decryption attempts with the same limit as that produced by the theorem for confidentiality alone. -For a target advantage of 2^-57, this results in: +For a target advantage of 2-57, this results in: ~~~ v + q <= 2^34.5 / l ~~~ By setting `q = v`, values for both confidentiality and integrity limits can be -produced. Endpoints that limit packets to 2^11 bytes therefore have both -confidentiality and integrity limits of 2^26.5 packets. Endpoints that do not -restrict packet size have a limit of 2^21.5. +produced. Endpoints that limit packets to 211 bytes therefore have +both confidentiality and integrity limits of 226.5 packets. Endpoints +that do not restrict packet size have a limit of 221.5. # Change Log diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index b0b91e3f7c..230fb0ec29 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -385,10 +385,10 @@ data in one direction: from the initiator of the stream to its peer. Bidirectional streams allow for data to be sent in both directions. Streams are identified within a connection by a numeric value, referred to as -the stream ID. A stream ID is a 62-bit integer (0 to 2^62-1) that is unique for -all streams on a connection. Stream IDs are encoded as variable-length -integers; see {{integer-encoding}}. A QUIC endpoint MUST NOT reuse a stream ID -within a connection. +the stream ID. A stream ID is a 62-bit integer (0 to 262-1) that is +unique for all streams on a connection. Stream IDs are encoded as +variable-length integers; see {{integer-encoding}}. A QUIC endpoint MUST NOT +reuse a stream ID within a connection. The least significant bit (0x1) of the stream ID identifies the initiator of the stream. Client-initiated streams have even-numbered stream IDs (with the bit @@ -1010,10 +1010,10 @@ MAX_STREAMS frames; see {{frame-max-streams}}. Separate limits apply to unidirectional and bidirectional streams. If a max_streams transport parameter or a MAX_STREAMS frame is received with a -value greater than 2^60, this would allow a maximum stream ID that cannot be -expressed as a variable-length integer; see {{integer-encoding}}. If either is -received, the connection MUST be closed immediately with a connection error of -type TRANSPORT_PARAMETER_ERROR if the offending value was received in a +value greater than 260, this would allow a maximum stream ID that +cannot be expressed as a variable-length integer; see {{integer-encoding}}. If +either is received, the connection MUST be closed immediately with a connection +error of type TRANSPORT_PARAMETER_ERROR if the offending value was received in a transport parameter or of type FRAME_ENCODING_ERROR if it was received in a frame; see {{immediate-close}}. @@ -3426,9 +3426,9 @@ Negotiation packet is coalesced with another packet. ## Packet Numbers {#packet-numbers} -The packet number is an integer in the range 0 to 2^62-1. This number is used -in determining the cryptographic nonce for packet protection. Each endpoint -maintains a separate packet number for sending and receiving. +The packet number is an integer in the range 0 to 262-1. This number +is used in determining the cryptographic nonce for packet protection. Each +endpoint maintains a separate packet number for sending and receiving. Packet numbers are limited to this range because they need to be representable in whole in the Largest Acknowledged field of an ACK frame ({{frame-ack}}). @@ -3463,10 +3463,10 @@ number by at least one. algorithms easier to implement between the two packet types. A QUIC endpoint MUST NOT reuse a packet number within the same packet number -space in one connection. If the packet number for sending reaches 2^62 - 1, the -sender MUST close the connection without sending a CONNECTION_CLOSE frame or any -further packets; an endpoint MAY send a Stateless Reset ({{stateless-reset}}) in -response to further packets that it receives. +space in one connection. If the packet number for sending reaches +262-1, the sender MUST close the connection without sending a +CONNECTION_CLOSE frame or any further packets; an endpoint MAY send a Stateless +Reset ({{stateless-reset}}) in response to further packets that it receives. A receiver MUST discard a newly unprotected packet unless it is certain that it has not processed another packet with the same packet number from the same @@ -4463,10 +4463,11 @@ value of fields. ## Packet Number Encoding and Decoding {#packet-encoding} -Packet numbers are integers in the range 0 to 2^62-1 ({{packet-numbers}}). When -present in long or short packet headers, they are encoded in 1 to 4 bytes. The -number of bits required to represent the packet number is reduced by including -only the least significant bits of the packet number. +Packet numbers are integers in the range 0 to 262-1 +({{packet-numbers}}). When present in long or short packet headers, they are +encoded in 1 to 4 bytes. The number of bits required to represent the packet +number is reduced by including only the least significant bits of the packet +number. The encoded packet number is protected as described in {{Section 5.4 of QUIC-TLS}}. @@ -5325,8 +5326,8 @@ max_ack_delay (0x0b): acknowledgments. This value SHOULD include the receiver's expected delays in alarms firing. For example, if a receiver sets a timer for 5ms and alarms commonly fire up to 1ms late, then it should send a max_ack_delay of 6ms. If - this value is absent, a default of 25 milliseconds is assumed. Values of 2^14 - or greater are invalid. + this value is absent, a default of 25 milliseconds is assumed. Values of + 214 or greater are invalid. disable_active_migration (0x0c): @@ -5776,9 +5777,9 @@ There is a separate flow of cryptographic handshake data in each encryption level, each of which starts at an offset of 0. This implies that each encryption level is treated as a separate CRYPTO stream of data. -The largest offset delivered on a stream - the sum of the offset and data -length - cannot exceed 2^62-1. Receipt of a frame that exceeds this limit MUST -be treated as a connection error of type FRAME_ENCODING_ERROR or +The largest offset delivered on a stream - the sum of the offset and data length +- cannot exceed 262-1. Receipt of a frame that exceeds this limit +MUST be treated as a connection error of type FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED. Unlike STREAM frames, which include a Stream ID indicating to which stream the @@ -5891,10 +5892,10 @@ When a Stream Data field has a length of 0, the offset in the STREAM frame is the offset of the next byte that would be sent. The first byte in the stream has an offset of 0. The largest offset delivered -on a stream - the sum of the offset and data length - cannot exceed 2^62-1, as -it is not possible to provide flow control credit for that data. Receipt of a -frame that exceeds this limit MUST be treated as a connection error of type -FRAME_ENCODING_ERROR or FLOW_CONTROL_ERROR. +on a stream - the sum of the offset and data length - cannot exceed +262-1, as it is not possible to provide flow control credit for that +data. Receipt of a frame that exceeds this limit MUST be treated as a +connection error of type FRAME_ENCODING_ERROR or FLOW_CONTROL_ERROR. ## MAX_DATA Frames {#frame-max-data} @@ -5996,11 +5997,11 @@ MAX_STREAMS frames contain the following field: Maximum Streams: -: A count of the cumulative number of streams of the corresponding type that - can be opened over the lifetime of the connection. This value cannot exceed - 2^60, as it is not possible to encode stream IDs larger than 2^62-1. - Receipt of a frame that permits opening of a stream larger than this limit - MUST be treated as a FRAME_ENCODING_ERROR. +: A count of the cumulative number of streams of the corresponding type that can + be opened over the lifetime of the connection. This value cannot exceed + 260, as it is not possible to encode stream IDs larger than + 262-1. Receipt of a frame that permits opening of a stream larger + than this limit MUST be treated as a FRAME_ENCODING_ERROR. Loss or reordering can cause a MAX_STREAMS frame to be received that state a lower stream limit than an endpoint has previously received. MAX_STREAMS frames @@ -6102,11 +6103,11 @@ STREAMS_BLOCKED frames contain the following field: Maximum Streams: -: A variable-length integer indicating the maximum number of streams allowed - at the time the frame was sent. This value cannot exceed 2^60, as it is - not possible to encode stream IDs larger than 2^62-1. Receipt of a frame - that encodes a larger stream ID MUST be treated as a STREAM_LIMIT_ERROR or a - FRAME_ENCODING_ERROR. +: A variable-length integer indicating the maximum number of streams allowed at + the time the frame was sent. This value cannot exceed 260, as it + is not possible to encode stream IDs larger than 262-1. Receipt of + a frame that encodes a larger stream ID MUST be treated as a + STREAM_LIMIT_ERROR or a FRAME_ENCODING_ERROR. ## NEW_CONNECTION_ID Frames {#frame-new-connection-id} @@ -7390,8 +7391,8 @@ assignment process {{!EARLY-ASSIGN=RFC7120}} can be used for these values. For codepoints that are encoded in variable-length integers ({{integer-encoding}}), such as frame types, codepoints that encode to four or -eight bytes (that is, values 2^14 and above) SHOULD be used unless the usage is -especially sensitive to having a longer encoding. +eight bytes (that is, values 214 and above) SHOULD be used unless the +usage is especially sensitive to having a longer encoding. Applications to register codepoints in QUIC registries MAY include a requested codepoint @@ -8020,8 +8021,8 @@ Issue and pull request numbers are listed with a leading octothorp. - Refine discussion of 0-RTT transport parameters (#2467, #2464) - Fewer transport parameters need to be remembered for 0-RTT (#2624, #2467) - Spin bit text incorporated (#2564) -- Close the connection when maximum stream ID in MAX_STREAMS exceeds 2^62 - 1 - (#2499, #2487) +- Close the connection when maximum stream ID in MAX_STREAMS exceeds + 262-1 (#2499, #2487) - New connection ID required for intentional migration (#2414, #2413) - Connection ID issuance can be rate-limited (#2436, #2428) - The "QUIC bit" is ignored in Version Negotiation (#2400, #2561)