10. Security Considerations
The security considerations of HTTP/3 should be comparable to those of HTTP/2 with TLS. However, many of the considerations from Section 10 of [HTTP/2] apply to [QUIC-TRANSPORT] and are discussed in that document.
10.1. Server Authority
HTTP/3 relies on the HTTP definition of authority. The security considerations of establishing authority are discussed in Section 17.1 of [HTTP].
10.2. Cross-Protocol Attacks
The use of ALPN in the TLS and QUIC handshakes establishes the target application protocol before application-layer bytes are processed. This ensures that endpoints have strong assurances that peers are using the same protocol.
This does not guarantee protection from all cross-protocol attacks. Section 21.5 of [QUIC-TRANSPORT] describes some ways in which the plaintext of QUIC packets can be used to perform request forgery against endpoints that don't use authenticated transports.
10.3. Intermediary-Encapsulation Attacks
The HTTP/3 field encoding allows the expression of names that are not valid field names in the syntax used by HTTP (Section 5.1 of [HTTP]). Requests or responses containing invalid field names MUST be treated as malformed.
Similarly, HTTP/3 can transport field values that are not valid. While most values that can be encoded will not alter field parsing, carriage return (ASCII 0x0d), line feed (ASCII 0x0a), and the null character (ASCII 0x00) might be exploited by an attacker if they are translated verbatim.
10.4. Cacheability of Pushed Responses
Pushed responses do not have an explicit request from the client; the request is provided by the server in the PUSH_PROMISE frame.
Where multiple tenants share space on the same server, that server MUST ensure that tenants are not able to push representations of resources that they do not have authority over.
10.5. Denial-of-Service Considerations
An HTTP/3 connection can demand a greater commitment of resources to operate than an HTTP/1.1 or HTTP/2 connection.
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.
An endpoint that does not monitor such behavior exposes itself to a risk of denial-of-service attack. Implementations SHOULD track the use of these features and set limits on their use.
10.5.1. Limits on Field Section Size
A large field section (Section 4.1) can cause an implementation to commit a large amount of state. An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE (Section 4.2.2) setting to advise peers of limits that might apply on the size of field sections.
10.5.2. CONNECT Issues
The CONNECT method can be used to create disproportionate load on a proxy, since stream creation is relatively inexpensive when compared to the creation and maintenance of a TCP connection.
10.6. Use of Compression
Compression can allow an attacker to recover secret data when it is compressed in the same context as data under attacker control. HTTP/3 enables compression of fields (Section 4.2).
Implementations communicating on a secure channel MUST NOT compress content that includes both confidential and attacker-controlled data unless separate compression contexts are used for each source of data.
10.7. Padding and Traffic Analysis
Padding can be used to obscure the exact size of frame content and is provided to mitigate specific attacks within HTTP.
10.8. Frame Parsing
Several protocol elements contain nested length elements. An implementation MUST ensure that the length of a frame exactly matches the length of the fields it contains.
10.9. Early Data
The use of 0-RTT with HTTP/3 creates an exposure to replay attack. The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when using HTTP/3 with 0-RTT.
10.10. Migration
Certain HTTP implementations use the client address for logging or access-control purposes. Since a QUIC client's address might change during a connection, such implementations will need to either actively retrieve the client's current address or explicitly accept that the original address might change.
10.11. Privacy Considerations
Several characteristics of HTTP/3 provide an observer an opportunity to correlate actions of a single client or server over time. These include the value of settings, the timing of reactions to stimulus, and the handling of any features that are controlled by settings.
HTTP/3's preference for using a single QUIC connection allows correlation of a user's activity on a site.