diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 312df73ba9..87dd1a7cd6 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -161,7 +161,7 @@ consumes a single QUIC stream. Streams are independent of each other, so one stream that is blocked or suffers packet loss does not prevent progress on other streams. -Server push is an interaction mode introduced in HTTP/2 {{?HTTP2}} which permits +Server push is an interaction mode introduced in HTTP/2 {{?HTTP2}} that permits a server to push a request-response exchange to a client in anticipation of the client making the indicated request. This trades off network usage against a potential latency gain. Several HTTP/3 frames are used to manage server push, @@ -291,7 +291,7 @@ draft-ietf-quic-transport-25. Non-compatible experiments that are based on these draft versions MUST append the string "-" and an experiment name to the identifier. For example, an -experimental implementation based on draft-ietf-quic-http-09 which reserves an +experimental implementation based on draft-ietf-quic-http-09 that reserves an extra stream for unsolicited transmission of 1980s pop music might identify itself as "h3-09-rickroll". Note that any label MUST conform to the "token" syntax defined in Section 5.4.1.1 of {{!SEMANTICS}}. Experimenters are @@ -354,7 +354,7 @@ indicated port of whatever host is identified within the authority component. Because HTTP/3 does not use TCP, HTTP/3 cannot be used for direct access to the authoritative server for a resource identified by an "http" URI. However, protocol extensions such as {{!ALTSVC=RFC7838}} permit the authoritative server -to identify other services which are also authoritative and which might be +to identify other services that are also authoritative and that might be reachable over HTTP/3. Prior to making requests for an origin whose scheme is not "https", the client @@ -464,7 +464,7 @@ A server MAY send one or more PUSH_PROMISE frames (see {{frame-push-promise}}) before, after, or interleaved with the frames of a response message. These PUSH_PROMISE frames are not part of the response; see {{server-push}} for more details. These frames are not permitted in pushed responses; a pushed response -which includes PUSH_PROMISE frames MUST be treated as a connection error of type +that includes PUSH_PROMISE frames MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. Frames of unknown types ({{extensions}}), including reserved frames @@ -612,7 +612,7 @@ All HTTP/3 requests MUST include exactly one value for the ":method", ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT request; see {{connect}}. -If the ":scheme" pseudo-header field identifies a scheme which has a mandatory +If the ":scheme" pseudo-header field identifies a scheme that has a mandatory authority component (including "http" and "https"), the request MUST contain either an ":authority" pseudo-header field or a "Host" header field. If these fields are present, they MUST NOT be empty. If both fields are present, they @@ -637,7 +637,7 @@ included in an HTTP/1.1 status line. #### Field Compression HTTP/3 uses QPACK field compression as described in [QPACK], a variation of -HPACK which allows the flexibility to avoid compression-induced head-of-line +HPACK that allows the flexibility to avoid compression-induced head-of-line blocking. See that document for additional details. To allow for better compression efficiency, the "Cookie" field {{!RFC6265}} MAY @@ -660,8 +660,8 @@ in bytes plus an overhead of 32 bytes for each field. If an implementation wishes to advise its peer of this limit, it can be conveyed as a number of bytes in the SETTINGS_MAX_FIELD_SECTION_SIZE parameter. An -implementation which has received this parameter SHOULD NOT send an HTTP message -header which exceeds the indicated size, as the peer will likely refuse to +implementation that has received this parameter SHOULD NOT send an HTTP message +header that exceeds the indicated size, as the peer will likely refuse to process it. However, because this limit is applied at each hop, messages below this limit are not guaranteed to be accepted. @@ -679,7 +679,7 @@ In this context, "processed" means that some data from the stream was passed to some higher layer of software that might have taken some action as a result. The client can treat requests rejected by the server as though they had never been sent at all, thereby allowing them to be retried later on a new connection. -Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests which +Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests that were partially or fully processed. When a server abandons a response after partial processing, it SHOULD abort its response stream with the error code H3_REQUEST_CANCELLED. @@ -772,7 +772,7 @@ The TCP connection can be closed by either peer. When the client ends the request stream (that is, the receive stream at the proxy enters the "Data Recvd" state), the proxy will set the FIN bit on its connection to the TCP server. When the proxy receives a packet with the FIN bit set, it will terminate the send -stream that it sends to the client. TCP connections which remain half-closed in +stream that it sends to the client. TCP connections that remain half-closed in a single direction are not invalid, but are often handled poorly by servers, so clients SHOULD NOT close a stream for sending while they still expect to receive data from the target of the CONNECT. @@ -793,7 +793,7 @@ or 101 (Switching Protocols) informational status code (Section 10.2.2 of ## Server Push -Server push is an interaction mode which permits a server to push a +Server push is an interaction mode that permits a server to push a request-response exchange to a client in anticipation of the client making the indicated request. This trades off network usage against a potential latency gain. HTTP/3 server push is similar to what is described in HTTP/2 {{?HTTP2}}, @@ -801,7 +801,7 @@ but uses different mechanisms. Each server push is identified by a unique Push ID. This Push ID is used in one or more PUSH_PROMISE frames (see {{frame-push-promise}}) that carry the request -fields, then included with the push stream which ultimately fulfills those +fields, then included with the push stream, which ultimately fulfills those promises. When the same Push ID is promised on multiple request streams, the decompressed request field sections MUST contain the same fields in the same order, and both the name and the value in each field MUST be exact @@ -816,10 +816,10 @@ with a Push ID that is greater than the maximum Push ID as a connection error of type H3_ID_ERROR. The header section of the request message is carried by a PUSH_PROMISE frame -(see {{frame-push-promise}}) on the request stream which generated the push. +(see {{frame-push-promise}}) on the request stream that generated the push. This allows the server push to be associated with a client request. -Not all requests can be pushed. A server MAY push requests which have the +Not all requests can be pushed. A server MAY push requests that have the following properties: - cacheable; see Section 8.2.3 of {{!SEMANTICS}} @@ -830,7 +830,7 @@ The server MUST include a value in the ":authority" pseudo-header field for which the server is authoritative; see {{connection-reuse}}. Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame -carrying a request which is not cacheable, is not known to be safe, that +carrying a request that is not cacheable, is not known to be safe, that indicates the presence of a request body, or for which it does not consider the server authoritative. @@ -968,7 +968,7 @@ 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 -continue fulfilling pushes which have already been promised, and the client can +continue fulfilling pushes that have already been promised, and the client can continue granting push credit as needed; see {{frame-max-push-id}}. 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 @@ -995,7 +995,7 @@ An HTTP/3 implementation can immediately close the QUIC connection at any time. This results in sending a QUIC CONNECTION_CLOSE frame to the peer indicating that the application layer has terminated the connection. The application error code in this frame indicates to the peer why the connection is being closed. -See {{errors}} for error codes which can be used when closing a connection in +See {{errors}} for error codes that can be used when closing a connection in HTTP/3. Before closing the connection, a GOAWAY frame MAY be sent to allow the client to @@ -1007,11 +1007,11 @@ clients. For various reasons, the QUIC transport could indicate to the application layer that the connection has terminated. This might be due to an explicit closure -by the peer, a transport-level error, or a change in network topology which +by the peer, a transport-level error, or a change in network topology that interrupts connectivity. If a connection terminates without a GOAWAY frame, clients MUST assume that any -request which was sent, whether in whole or in part, might have been processed. +request that was sent, whether in whole or in part, might have been processed. # Stream Mapping and Usage {#stream-mapping} @@ -1091,14 +1091,14 @@ control stream as well as the unidirectional streams required by mandatory extensions (such as the QPACK encoder and decoder streams) first, and then create additional streams as allowed by their peer. -If the stream header indicates a stream type which is not supported by the +If the stream header indicates a stream type that is not supported by the recipient, the remainder of the stream cannot be consumed as the semantics are unknown. Recipients of unknown stream types MAY abort reading of the stream with an error code of H3_STREAM_CREATION_ERROR, but MUST NOT consider such streams to be a connection error of any kind. Implementations MAY send stream types before knowing whether the peer supports -them. However, stream types which could modify the state or semantics of +them. However, stream types that could modify the state or semantics of existing protocol components, including QPACK or other extensions, MUST NOT be sent until the peer is known to support them. @@ -1115,7 +1115,7 @@ Each side MUST initiate a single control stream at the beginning of the connection and send its SETTINGS frame as the first frame on this stream. If the first frame of the control stream is any other frame type, this MUST be treated as a connection error of type H3_MISSING_SETTINGS. Only one control -stream per peer is permitted; receipt of a second stream which claims to be a +stream per peer is permitted; receipt of a second stream claiming to be a control stream MUST be treated as a connection error of type H3_STREAM_CREATION_ERROR. The sender MUST NOT close the control stream, and the receiver MUST NOT request that the sender close the control stream. If @@ -1176,9 +1176,9 @@ either the H3_NO_ERROR error code or a reserved error code HTTP frames are carried on QUIC streams, as described in {{stream-mapping}}. HTTP/3 defines three stream types: control stream, request stream, and push -stream. This section describes HTTP/3 frame formats and the streams types on -which they are permitted; see {{stream-frame-mapping}} for an overview. A -comparison between HTTP/2 and HTTP/3 frames is provided in {{h2-frames}}. +stream. This section describes HTTP/3 frame formats and their permitted stream +types; see {{stream-frame-mapping}} for an overview. A comparison between +HTTP/2 and HTTP/3 frames is provided in {{h2-frames}}. | Frame | Control Stream | Request Stream | Push Stream | Section | | -------------- | -------------- | -------------- | ----------- | ------------------------ | @@ -1231,7 +1231,7 @@ H3_FRAME_ERROR. When a stream terminates cleanly, if the last frame on the stream was truncated, this MUST be treated as a connection error ({{errors}}) of type -H3_FRAME_ERROR. Streams which terminate abruptly may be reset at any point in +H3_FRAME_ERROR. Streams that terminate abruptly may be reset at any point in a frame. ## Frame Definitions {#frames} @@ -1314,7 +1314,7 @@ CANCEL_PUSH Frame { The CANCEL_PUSH frame carries a Push ID encoded as a variable-length integer. The Push ID identifies the server push that is being cancelled; see -{{frame-push-promise}}. If a CANCEL_PUSH frame is received which references a +{{frame-push-promise}}. If a CANCEL_PUSH frame is received that references a Push ID greater than currently allowed on the connection, this MUST be treated as a connection error of type H3_ID_ERROR. @@ -1344,7 +1344,7 @@ If an endpoint receives a SETTINGS frame on a different stream, the endpoint MUST respond with a connection error of type H3_FRAME_UNEXPECTED. SETTINGS parameters are not negotiated; they describe characteristics of the -sending peer, which can be used by the receiving peer. However, a negotiation +sending peer that can be used by the receiving peer. However, a negotiation can be implied by the use of SETTINGS - each peer uses SETTINGS to advertise a set of supported values. The definition of the setting would describe how each peer combines the two sets to conclude which choice will be used. SETTINGS does @@ -1401,7 +1401,7 @@ for more details. #### Initialization {#settings-initialization} -An HTTP implementation MUST NOT send frames or requests which would be invalid +An HTTP implementation MUST NOT send frames or requests that would be invalid based on its current understanding of the peer's settings. All settings begin at an initial value. Each endpoint SHOULD use these initial @@ -1443,7 +1443,7 @@ complying with those settings would not violate the server's current settings. A server MAY accept 0-RTT and subsequently provide different settings in its SETTINGS frame. If 0-RTT data is accepted by the server, its SETTINGS frame MUST NOT reduce any limits or alter any values that might be violated by the client -with its 0-RTT data. The server MUST include all settings which differ from +with its 0-RTT data. The server MUST include all settings that differ from their default values. If a server accepts 0-RTT but then sends settings that are not compatible with the previously specified settings, this MUST be treated as a connection error of type H3_SETTINGS_ERROR. If a server accepts 0-RTT but @@ -1588,7 +1588,7 @@ consider these frames to have any meaning upon receipt. The payload and length of the frames are selected in any manner the implementation chooses. -Frame types which were used in HTTP/2 where there is no corresponding HTTP/3 +Frame types that were used in HTTP/2 where there is no corresponding HTTP/3 frame have also been reserved ({{iana-frames}}). These frame types MUST NOT be sent, and receipt MAY be treated as an error of type H3_FRAME_UNEXPECTED. @@ -1609,7 +1609,7 @@ use of an error code in an unexpected context or receipt of an unknown error code MUST be treated as equivalent to H3_NO_ERROR. However, closing a stream can have other effects regardless of the error code; see {{request-response}}. -This section describes HTTP/3-specific error codes which can be used to express +This section describes HTTP/3-specific error codes that can be used to express the cause of a connection or stream error. ## HTTP/3 Error Codes {#http-error-codes} @@ -1622,7 +1622,7 @@ H3_NO_ERROR (0x100): there is no error to signal. H3_GENERAL_PROTOCOL_ERROR (0x101): -: Peer violated protocol requirements in a way which doesn't match a more +: Peer violated protocol requirements in a way that doesn't match a more specific error code, or endpoint declines to use the more specific error code. H3_INTERNAL_ERROR (0x102): @@ -1635,7 +1635,7 @@ H3_CLOSED_CRITICAL_STREAM (0x104): : A stream required by the connection was closed or reset. H3_FRAME_UNEXPECTED (0x105): -: A frame was received which was not permitted in the current state or on the +: A frame was received that was not permitted in the current state or on the current stream. H3_FRAME_ERROR (0x106): @@ -1737,7 +1737,7 @@ of establishing authority are discussed in Section 12.1 of {{!SEMANTICS}}. The use of ALPN in the TLS and QUIC handshakes establishes the target application protocol before application-layer bytes are processed. Because all QUIC packets are encrypted, it is difficult for an attacker to control the -plaintext bytes of an HTTP/3 connection which could be used in a cross-protocol +plaintext bytes of an HTTP/3 connection, which could be used in a cross-protocol attack on a plaintext protocol. ## Intermediary Encapsulation Attacks @@ -1789,7 +1789,7 @@ time. Processing capacity cannot be guarded as effectively as state capacity. -The ability to send undefined protocol elements which the peer is required to +The ability to send undefined protocol elements that the peer is required to ignore can be abused to cause a peer to expend additional processing time. This might be done by setting multiple undefined SETTINGS parameters, unknown frame types, or unknown stream types. Note, however, that some uses are entirely @@ -2194,7 +2194,7 @@ not required. This permits the removal of the Flags field from the generic frame layout. Frame payloads are largely drawn from {{?HTTP2}}. However, QUIC includes many -features (e.g., flow control) which are also present in HTTP/2. In these cases, +features (e.g., flow control) that are also present in HTTP/2. In these cases, the HTTP mapping does not re-implement them. As a result, several HTTP/2 frame types are not required in HTTP/3. Where an HTTP/2-defined frame is no longer used, the frame ID has been reserved in order to maximize portability between @@ -2229,7 +2229,7 @@ endpoints remains in sync. Because this total ordering is not provided by QUIC, HTTP/3 uses a modified version of HPACK, called QPACK. QPACK uses a single unidirectional stream to make all modifications to the dynamic table, ensuring a total order of updates. -All frames which contain encoded fields merely reference the table state at a +All frames that contain encoded fields merely reference the table state at a given time without modifying it. [QPACK] provides additional details. @@ -2244,7 +2244,7 @@ IDs). Redefinition of the encoding of extension frame types might be necessary if the encoding includes a Stream ID. Because the Flags field is not present in generic HTTP/3 frames, those frames -which depend on the presence of flags need to allocate space for flags as part +that depend on the presence of flags need to allocate space for flags as part of their frame payload. Other than this issue, frame type HTTP/2 extensions are typically portable to @@ -2316,7 +2316,7 @@ SETTINGS_HEADER_TABLE_SIZE: : See [QPACK]. SETTINGS_ENABLE_PUSH: -: This is removed in favor of the MAX_PUSH_ID which provides a more granular +: This is removed in favor of the MAX_PUSH_ID, which provides a more granular control over server push. SETTINGS_MAX_CONCURRENT_STREAMS: @@ -2338,7 +2338,7 @@ SETTINGS_MAX_HEADER_LIST_SIZE: In HTTP/3, setting values are variable-length integers (6, 14, 30, or 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. This will often -produce a shorter encoding, but can produce a longer encoding for settings which +produce a shorter encoding, but can produce a longer encoding for settings that use the full 32-bit space. Settings ported from HTTP/2 might choose to redefine their value to limit it to 30 bits for more efficient encoding, or to make use of the 62-bit space if more than 30 bits are required. diff --git a/draft-ietf-quic-invariants.md b/draft-ietf-quic-invariants.md index 2e0838ba9b..a29f5d3673 100644 --- a/draft-ietf-quic-invariants.md +++ b/draft-ietf-quic-invariants.md @@ -263,7 +263,7 @@ version numbers are potentially valid. The properties described in this document apply to all versions of QUIC. A protocol that does not conform to the properties described in this document is -not QUIC. Future documents might describe additional properties which apply to +not QUIC. Future documents might describe additional properties that apply to a specific QUIC version, or to a range of QUIC versions. diff --git a/draft-ietf-quic-qpack.md b/draft-ietf-quic-qpack.md index 4bd21e3d70..110e2cae68 100644 --- a/draft-ietf-quic-qpack.md +++ b/draft-ietf-quic-qpack.md @@ -152,16 +152,16 @@ Field section: Representation: -: An instruction which represents a field line, possibly by reference to the +: An instruction that represents a field line, possibly by reference to the dynamic and static tables. Encoder: -: An implementation which encodes field sections. +: An implementation that encodes field sections. Decoder: -: An implementation which decodes encoded field sections. +: An implementation that decodes encoded field sections. Absolute Index: @@ -169,7 +169,7 @@ Absolute Index: Base: -: A reference point for relative and post-base indices. Representations which +: A reference point for relative and post-base indices. Representations that reference dynamic table entries are relative to a Base. Insert Count: @@ -230,7 +230,7 @@ while the decoder is relatively simple. ### Limits on Dynamic Table Insertions {#blocked-insertion} Inserting entries into the dynamic table might not be possible if the table -contains entries which cannot be evicted. +contains entries that cannot be evicted. A dynamic table entry cannot be evicted immediately after insertion, even if it has never been referenced. Once the insertion of a dynamic table entry has been @@ -241,7 +241,7 @@ because those references are guaranteed to be processed before the instruction evicting the entry. If the dynamic table does not contain enough room for a new entry without -evicting other entries, and the entries which would be evicted are not +evicting other entries, and the entries that would be evicted are not evictable, the encoder MUST NOT insert that entry into the dynamic table (including duplicates of existing entries). In order to avoid this, an encoder that uses the dynamic table has to keep track of each dynamic table entry @@ -297,14 +297,14 @@ When the decoder receives an encoded field section with a Required Insert Count greater than its own Insert Count, the stream cannot be processed immediately, and is considered "blocked"; see {{blocked-decoding}}. -The decoder specifies an upper bound on the number of streams which can be +The decoder specifies an upper bound on the number of streams that can be blocked using the SETTINGS_QPACK_BLOCKED_STREAMS setting; see {{configuration}}. -An encoder MUST limit the number of streams which could become blocked to the +An encoder MUST limit the number of streams that could become blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS at all times. If a decoder encounters more blocked streams than it promised to support, it MUST treat this as a connection error of type QPACK_DECOMPRESSION_FAILED. -Note that the decoder might not become blocked on every stream which risks +Note that the decoder might not become blocked on every stream that risks becoming blocked. An encoder can decide whether to risk having a stream become blocked. If @@ -312,7 +312,7 @@ permitted by the value of SETTINGS_QPACK_BLOCKED_STREAMS, compression efficiency can often be improved by referencing dynamic table entries that are still in transit, but if there is loss or reordering the stream can become blocked at the decoder. An encoder can avoid the risk of blocking by only referencing dynamic -table entries which have been acknowledged, but this could mean using literals. +table entries that have been acknowledged, but this could mean using literals. Since literals make the encoded field section larger, this can result in the encoder becoming blocked on congestion or flow control limits. @@ -435,13 +435,13 @@ acknowledged before using it. ### Invalid References If the decoder encounters a reference in a field line representation to a -dynamic table entry which has already been evicted or which has an absolute +dynamic table entry that has already been evicted or that has an absolute index greater than or equal to the declared Required Insert Count ({{header-prefix}}), it MUST treat this as a connection error of type QPACK_DECOMPRESSION_FAILED. If the decoder encounters a reference in an encoder instruction to a dynamic -table entry which has already been evicted, it MUST treat this as a connection +table entry that has already been evicted, it MUST treat this as a connection error of type QPACK_ENCODER_STREAM_ERROR. @@ -548,7 +548,7 @@ encoder stream. ### Absolute Indexing {#indexing} -Each entry possesses an absolute index which is fixed for the lifetime of that +Each entry possesses an absolute index that is fixed for the lifetime of that entry. The first entry inserted has an absolute index of "0"; indices increase by one with each insertion. @@ -700,7 +700,7 @@ An encoder sends encoder instructions on the encoder stream to set the capacity of the dynamic table and add dynamic table entries. Instructions adding table entries can use existing entries to avoid transmitting redundant information. The name can be transmitted as a reference to an existing entry in the static or -the dynamic table or as a string literal. For entries which already exist in +the dynamic table or as a string literal. For entries that already exist in the dynamic table, the full entry can also be used by reference, creating a duplicate entry. @@ -709,7 +709,7 @@ This section specifies the following encoder instructions. ### Set Dynamic Table Capacity {#set-dynamic-capacity} An encoder informs the decoder of a change to the dynamic table capacity using -an instruction which begins with the '001' three-bit pattern. This is followed +an instruction that begins with the '001' three-bit pattern. This is followed by the new dynamic table capacity represented as an integer with a 5-bit prefix; see {{prefixed-integers}}. @@ -728,7 +728,7 @@ the decoder. The decoder MUST treat a new dynamic table capacity value that exceeds this limit as a connection error of type QPACK_ENCODER_STREAM_ERROR. Reducing the dynamic table capacity can cause entries to be evicted; see -{{eviction}}. This MUST NOT cause the eviction of entries which are not +{{eviction}}. This MUST NOT cause the eviction of entries that are not evictable; see {{blocked-insertion}}. Changing the capacity of the dynamic table is not acknowledged as this instruction does not insert an entry. @@ -816,7 +816,7 @@ This section specifies the following decoder instructions. After processing an encoded field section whose declared Required Insert Count is not zero, the decoder emits a Section Acknowledgement instruction. The -instruction begins with the '1' one-bit pattern which is followed by the field +instruction begins with the '1' one-bit pattern, followed by the field section's associated stream ID encoded as a 7-bit prefix integer; see {{prefixed-integers}}. @@ -844,7 +844,7 @@ see {{known-received-count}}. When a stream is reset or reading is abandoned, the decoder emits a Stream Cancellation instruction. The instruction begins with the '01' two-bit -pattern, which is followed by the stream ID of the affected stream encoded as a +pattern, followed by the stream ID of the affected stream encoded as a 6-bit prefix integer. This instruction is used as described in {{state-synchronization}}. @@ -1000,7 +1000,7 @@ A single-pass encoder determines the Base before encoding a field section. If the encoder inserted entries in the dynamic table while encoding the field section, Required Insert Count will be greater than the Base, so the encoded difference is negative and the sign bit is set to 1. If the field section was -not encoded using representations which reference the most recent entry in the +not encoded using representations that reference the most recent entry in the table and did not insert any new entries, the Base will be greater than the Required Insert Count, so the delta will be positive and the sign bit is set to 0. @@ -1153,7 +1153,7 @@ represented as a 4-bit prefix string literal, then the value, represented as an # Configuration -QPACK defines two settings which are included in the HTTP/3 SETTINGS frame. +QPACK defines two settings for the HTTP/3 SETTINGS frame: SETTINGS_QPACK_MAX_TABLE_CAPACITY (0x1): : The default value is zero. See {{header-table-dynamic}} for usage. This is @@ -1166,7 +1166,7 @@ QPACK defines two settings which are included in the HTTP/3 SETTINGS frame. # Error Handling {#error-handling} The following error codes are defined for HTTP/3 to indicate failures of -QPACK which prevent the connection from continuing: +QPACK that prevent the connection from continuing: QPACK_DECOMPRESSION_FAILED (0x200): : The decoder failed to interpret an encoded field section and is not able to @@ -1376,7 +1376,7 @@ header list for other reasons; even if QPACK does not force this to occur, application constraints might make this necessary. While the negotiated limit on the dynamic table size accounts for much of the -memory that can be consumed by a QPACK implementation, data which cannot be +memory that can be consumed by a QPACK implementation, data that cannot be immediately sent due to flow control is not affected by this limit. Implementations should limit the size of unsent data, especially on the decoder stream where flexibility to choose what to send is limited. Possible responses diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 7b000ea7a2..02a67a5298 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -167,7 +167,7 @@ Layer | Records | Each Handshake layer message (e.g., Handshake, Alerts, and Application Data) is carried as a series of typed TLS records by the Record layer. Records are individually cryptographically protected and then transmitted over a reliable -transport (typically TCP) which provides sequencing and guaranteed delivery. +transport (typically TCP), which provides sequencing and guaranteed delivery. The TLS authenticated key exchange occurs between two endpoints: client and server. The client initiates the exchange and the server responds. If the key @@ -187,11 +187,11 @@ shared secrets that cannot be controlled by either participating peer. TLS provides two basic handshake modes of interest to QUIC: - * A full 1-RTT handshake in which the client is able to send Application Data + * A full 1-RTT handshake, in which the client is able to send Application Data after one round trip and the server immediately responds after receiving the first handshake message from the client. - * A 0-RTT handshake in which the client uses information it has previously + * A 0-RTT handshake, in which the client uses information it has previously learned about the server to send Application Data immediately. This Application Data can be replayed by an attacker so it MUST NOT carry a self-contained trigger for any non-idempotent action. @@ -306,9 +306,9 @@ protection being called out specially. ~~~ {: #schematic title="QUIC and TLS Interactions"} -Unlike TLS over TCP, QUIC applications which want to send data do not send it +Unlike TLS over TCP, QUIC applications that want to send data do not send it through TLS "application_data" records. Rather, they send it as QUIC STREAM -frames or other frame types which are then carried in QUIC packets. +frames or other frame types, which are then carried in QUIC packets. # Carrying TLS Messages {#carrying-tls} @@ -341,7 +341,7 @@ data packet number space: number space. - ACK frames MAY appear in any packet number space, but can only acknowledge - packets which appeared in that packet number space. However, as noted below, + packets that appeared in that packet number space. However, as noted below, 0-RTT packets cannot contain ACK frames. - All other frame types MUST only be sent in the application data packet number @@ -459,7 +459,7 @@ network, it proceeds as follows: process is that new data is available, then it is delivered to TLS in order. - If the packet is from a previously installed encryption level, it MUST NOT - contain data which extends past the end of previously received data in that + contain data that extends past the end of previously received data in that flow. Implementations MUST treat any violations of this requirement as a connection error of type PROTOCOL_VIOLATION. @@ -1061,7 +1061,7 @@ Header protection is applied after packet protection is applied (see {{aead}}). The ciphertext of the packet is sampled and used as input to an encryption algorithm. The algorithm used depends on the negotiated AEAD. -The output of this algorithm is a 5-byte mask which is applied to the protected +The output of this algorithm is a 5-byte mask that is applied to the protected header fields using exclusive OR. The least significant bits of the first byte of the packet are masked by the least significant bits of the first mask byte, and the packet number is masked with the remaining bytes. Any unused bytes of @@ -1668,7 +1668,7 @@ For example, an attacker could inject a packet containing an ACK frame that makes it appear that a packet had not been received or to create a false impression of the state of the connection (e.g., by modifying the ACK Delay). Note that such a packet could cause a legitimate packet to be dropped as a -duplicate. Implementations SHOULD use caution in relying on any data which is +duplicate. Implementations SHOULD use caution in relying on any data that is contained in Initial packets that is not otherwise authenticated. It is also possible for the attacker to tamper with data that is carried in @@ -1853,7 +1853,7 @@ limit the level of amplification. ## Header Protection Analysis {#header-protect-analysis} {{?NAN=DOI.10.1007/978-3-030-26948-7_9}} analyzes authenticated encryption -algorithms which provide nonce privacy, referred to as "Hide Nonce" (HN) +algorithms that provide nonce privacy, referred to as "Hide Nonce" (HN) transforms. The general header protection construction in this document is one of those algorithms (HN1). Header protection uses the output of the packet protection AEAD to derive `sample`, and then encrypts the header field using diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 6b83f87ebf..0c7fc71d2f 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1045,7 +1045,7 @@ The primary function of a connection ID is to ensure that changes in addressing at lower protocol layers (UDP, IP) don't cause packets for a QUIC connection to be delivered to the wrong endpoint. Each endpoint selects connection IDs using an implementation-specific (and perhaps -deployment-specific) method which will allow packets with that connection ID to +deployment-specific) method that will allow packets with that connection ID to be routed back to the endpoint and to be identified by the endpoint upon receipt. @@ -3028,7 +3028,7 @@ sends a Stateless Reset to another server it might receive another Stateless Reset in response, which could lead to an infinite exchange. An endpoint MUST ensure that every Stateless Reset that it sends is smaller than -the packet which triggered it, unless it maintains state sufficient to prevent +the packet that triggered it, unless it maintains state sufficient to prevent looping. In the event of a loop, this results in packets eventually being too small to trigger a response. @@ -3079,7 +3079,7 @@ Disposing of connection state prior to the end of the closing or draining period could cause delayed or reordered packets to generate an unnecessary stateless reset. Endpoints that have some alternative means to ensure that late-arriving packets on the connection do not induce a response, such as those that are able -to close the UDP socket, MAY use an abbreviated draining period which can allow +to close the UDP socket, MAY use an abbreviated draining period to allow for faster resource recovery. Servers that retain an open socket for accepting new connections SHOULD NOT exit the closing or draining period early. @@ -3219,7 +3219,7 @@ packet sent in a given packet number space; see {{packet-numbers}} for details. ## Coalescing Packets {#packet-coalesce} Initial ({{packet-initial}}), 0-RTT ({{packet-0rtt}}), and Handshake -({{packet-handshake}}) packets contain a Length field, which determines the end +({{packet-handshake}}) packets contain a Length field that determines the end of the packet. The length includes both the Packet Number and Payload fields, both of which are confidentiality protected and initially of unknown length. The length of the Payload field is learned once header protection is @@ -3285,7 +3285,7 @@ As described in {{QUIC-TLS}}, each packet type uses different protection keys. Conceptually, a packet number space is the context in which a packet can be processed and acknowledged. Initial packets can only be sent with Initial -packet protection keys and acknowledged in packets which are also Initial +packet protection keys and acknowledged in packets that are also Initial packets. Similarly, Handshake packets are sent at the Handshake encryption level and can only be acknowledged in Handshake packets. @@ -3525,7 +3525,7 @@ endpoint MUST NOT send more than one such packet in response to receiving an ack-eliciting packet. An endpoint MUST NOT send a non-ack-eliciting packet in response to a -non-ack-eliciting packet, even if there are packet gaps which precede the +non-ack-eliciting packet, even if there are packet gaps that precede the received packet. This avoids an infinite feedback loop of acknowledgements, which could prevent the connection from ever becoming idle. Non-ack-eliciting packets are eventually acknowledged when the endpoint sends an ACK frame in @@ -4325,8 +4325,8 @@ Type-Specific Bits: Version: : The QUIC Version is a 32-bit field that follows the first byte. This field - indicates which version of QUIC is in use and determines how the rest of the - protocol fields are interpreted. + indicates the version of QUIC that is in use and determines how the rest of + the protocol fields are interpreted. Destination Connection ID Length: @@ -4395,7 +4395,7 @@ Reserved Bits: Packet Number Length: -: In packet types which contain a Packet Number field, the least significant two +: In packet types that contain a Packet Number field, the least significant two bits (those with a mask of 0x03) of byte 0 contain the length of the packet number, encoded as an unsigned, two-bit integer that is one less than the length of the packet number field in bytes. That is, the length of the packet @@ -4460,7 +4460,7 @@ limit, Version Negotiation packets could carry Connection IDs that are longer than 20 bytes. The remainder of the Version Negotiation packet is a list of 32-bit versions -which the server supports. +that the server supports. A Version Negotiation packet is not acknowledged. It is only sent in response to a packet that indicates an unsupported version; see {{server-pkt-handling}}. @@ -4794,7 +4794,7 @@ PROTOCOL_VIOLATION. ## Short Header Packets {#short-header} -This version of QUIC defines a single packet type which uses the +This version of QUIC defines a single packet type that uses the short packet header. ~~~ @@ -4955,7 +4955,7 @@ Transport Parameter { The Transport Parameter Length field contains the length of the Transport Parameter Value field. -QUIC encodes transport parameters into a sequence of bytes, which are then +QUIC encodes transport parameters into a sequence of bytes, which is then included in the cryptographic handshake. @@ -5303,7 +5303,7 @@ First ACK Range: ACK Ranges: -: Contains additional ranges of packets which are alternately not +: Contains additional ranges of packets that are alternately not acknowledged (Gap) and acknowledged (ACK Range); see {{ack-ranges}}. ECN Counts: @@ -5448,7 +5448,7 @@ Stream ID: Application Protocol Error Code: : A variable-length integer containing the application protocol error - code (see {{app-error-codes}}) which indicates why the stream is being + code (see {{app-error-codes}}) that indicates why the stream is being closed. Final Size: @@ -5760,9 +5760,9 @@ Maximum Streams: 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 which states a +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 -which do not increase the stream limit MUST be ignored. +that do not increase the stream limit MUST be ignored. An endpoint MUST NOT open more streams than permitted by the current stream limit set by its peer. For instance, a server that receives a unidirectional @@ -5825,7 +5825,7 @@ STREAM_DATA_BLOCKED frames contain the following fields: Stream ID: -: A variable-length integer indicating the stream which is blocked due to flow +: A variable-length integer indicating the stream that is blocked due to flow control. Maximum Stream Data: @@ -6068,7 +6068,7 @@ CONNECTION_CLOSE frames contain the following fields: Error Code: -: A variable-length integer error code which indicates the reason for +: A variable-length integer error code that indicates the reason for closing this connection. A CONNECTION_CLOSE frame of type 0x1c uses codes from the space defined in {{transport-error-codes}}. A CONNECTION_CLOSE frame of type 0x1d uses codes from the application protocol error code space; see @@ -6266,7 +6266,7 @@ ability of an attacker to interfere with existing connections. Once a connection is established QUIC endpoints might accept some unauthenticated ICMP packets (see {{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 +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 @@ -6457,7 +6457,7 @@ be influenced by an attacker. ## Version Downgrade {#version-downgrade} This document defines QUIC Version Negotiation packets in -{{version-negotiation}}, which can be used to negotiate the QUIC version used +{{version-negotiation}} that can be used to negotiate the QUIC version used between two endpoints. However, this document does not specify how this negotiation will be performed between this version and subsequent future versions. In particular, Version Negotiation packets do not contain any @@ -6542,9 +6542,9 @@ path are limited. Computing the server's first flight for a full handshake is potentially expensive, requiring both a signature and a key exchange computation. In order to prevent computational DoS attacks, the Retry packet provides a cheap token -exchange mechanism which allows servers to validate a client's IP address prior +exchange mechanism that allows servers to validate a client's IP address prior to doing any expensive computations at the cost of a single round trip. After a -successful handshake, servers can issue new tokens to a client which will allow +successful handshake, servers can issue new tokens to a client, which will allow new connection establishment without incurring this cost. @@ -6594,7 +6594,7 @@ future time; this is true for any observer of any packet on any network. A blind attacker, one who injects packets without being able to observe valid packets for a connection, is unlikely to be successful, since packet protection -ensures that valid packets are only generated by endpoints which possess the +ensures that valid packets are only generated by endpoints that possess the key material established during the handshake; see {{handshake}} and {{handshake-properties}}. Similarly, any active attacker that observes packets and attempts to insert new data or modify existing data in those packets should