Draft: draft-ietf-quic-http

Commentary: The follow - on to ; depends on . DO NOT MERGE before lands . Imports most of the HTTP/2 Security Considerations text , modulo updates to reference HTTP/3 or http - core concepts . Suggestions on a more sensible structuring of concerns welcome ; this still feels like a bit of a grab - bag . 
 There 's a few places where it seems the new " field " terminology is applied inconsistently , but given the PR dependency chain maybe that will shake out . I 'll take another look once other things have landed . 
 Given the chain , this PR should consistently use the new terminology . If I missed something , please flag it . 
 HTTP - core is making some terminology changes that HTTP/3 should track : In , " non - final " responses are " interim " responses In , terminology around header , field , value is changing Related to , but this is more than just pointing at the new documents . 
 these comments / suggestion address my earlier one about use of headers . I might be applying things wrong . Looks good to me . Thanks for doing the hard work here .
Paragraph (version A):
the inclusion of uppercase field names.
Paragraph (version B):
an invalid sequence of HTTP messages,
Paragraph (version A):
The security considerations of HTTP/3 should be comparable to those
of HTTP/2 with TLS; the considerations from Section 10 of HTTP2 apply
in addition to those listed here.
Paragraph (version A):
TODO: This is going to be a big import, probably worthy of its own
PR.
Paragraph (version A):
When HTTP Alternative Services is used for discovery for HTTP/3
endpoints, the security considerations of ALTSVC also apply.
Paragraph (version B):
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 HTTP2 apply to QUIC-TRANSPORT and are discussed in that
document.
Paragraph (version B):
HTTP/3 relies on the HTTP definition of authority.  The security
considerations of establishing authority are discussed in
Section 11.1 of SEMANTICS.
Paragraph (version B):
The HTTP/3 field encoding allows the expression of names that are not
valid field names in the syntax used by HTTP (Section 4.3 of
SEMANTICS).  Requests or responses containing invalid field names
MUST be treated as malformed (malformed).  An intermediary therefore
cannot translate an HTTP/3 request or response containing an invalid
field name into an HTTP/1.1 message.
Paragraph (version B):
Similarly, HTTP/3 allows field values that are not valid.  While most
of the values that can be encoded will not alter field parsing,
carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the
zero character (NUL, ASCII 0x0) might be exploited by an attacker if
they are translated verbatim.  Any request or response that contains
a character not permitted in a field value MUST be treated as
malformed (malformed).  Valid characters are defined by the "field-
content" ABNF rule in Section 4.4 of SEMANTICS.
Paragraph (version B):
Pushed responses do not have an explicit request from the client; the
request is provided by the server in the PUSH_PROMISE frame.
Paragraph (version B):
Caching responses that are pushed is possible based on the guidance
provided by the origin server in the Cache-Control header field.
However, this can cause issues if a single server hosts more than one
tenant.  For example, a server might offer multiple users each a
small portion of its URI space.
Paragraph (version B):
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.  Failure to enforce
this would allow a tenant to provide a representation that would be
served out of cache, overriding the actual representation that the
authoritative tenant provides.
Paragraph (version B):
Pushed responses for which an origin server is not authoritative (see
connection-reuse) MUST NOT be used or cached.
Paragraph (version B):
An HTTP/3 connection can demand a greater commitment of resources to
operate than an HTTP/1.1 or HTTP/2 connection.  The use of field
compression and flow control depend on a commitment of resources for
storing a greater amount of state.  Settings for these features
ensure that memory commitments for these features are strictly
bounded.
Paragraph (version B):
The number of PUSH_PROMISE frames is constrained in a similar
fashion.  A client that accepts server push SHOULD limit the number
of Push IDs it issues at a time.
Paragraph (version B):
Processing capacity cannot be guarded as effectively as state
capacity.
Paragraph (version B):
Compression of field sections also offers some opportunities to waste
processing resources; see Section 7 of QPACK for more details on
potential abuses.
Paragraph (version B):
All these features - i.e., server push, unknown protocol elements,
field compression - have legitimate uses.  These features become a
burden only when they are used unnecessarily or to excess.
Paragraph (version B):
An endpoint can use the SETTINGS_MAX_HEADER_LIST_SIZE (settings-
parameters) setting to advise peers of limits that might apply on the
size of field sections.  This setting is only advisory, so endpoints
MAY choose to send field sections that exceed this limit and risk
having the request or response being treated as malformed.  This
setting is specific to a connection, so any request or response could
encounter a hop with a lower, unknown limit.  An intermediary can
attempt to avoid this problem by passing on values presented by
different peers, but they are not obligated to do so.
Paragraph (version B):
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 (header-formatting); the
following concerns also apply to the use of HTTP compressed content-
codings; see Section 6.1.2 of SEMANTICS.
Paragraph (version B):
There are demonstrable attacks on compression that exploit the
characteristics of the web (e.g., BREACH).  The attacker induces
multiple requests containing varying plaintext, observing the length
of the resulting ciphertext in each, which reveals a shorter length
when a guess about the secret is correct.
Paragraph (version B):
Padding can be used to obscure the exact size of frame content and is
provided to mitigate specific attacks within HTTP, for example,
attacks where compressed content includes both attacker-controlled
plaintext and secret data (e.g., BREACH).
Paragraph (version B):
Where HTTP/2 employs PADDING frames and Padding fields in other
frames to make a connection more resistant to traffic analysis,
HTTP/3 can either rely on transport-layer padding or employ the
reserved frame and stream types discussed in frame-reserved and
stream-grease.  These methods of padding produce different results in
terms of the granularity of padding, how padding is arranged in
relation to the information that is being protected, whether padding
is applied in the case of packet loss, and how an implementation
might control padding.  Redundant padding could even be
counterproductive.
Paragraph (version B):
To mitigate attacks that rely on compression, disabling or limiting
compression might be preferable to padding as a countermeasure.
Paragraph (version B):
Use of padding can result in less protection than might seem
immediately obvious.  At best, padding only makes it more difficult
for an attacker to infer length information by increasing the number
of frames an attacker has to observe.  Incorrectly implemented
padding schemes can be easily defeated.  In particular, randomized
padding with a predictable distribution provides very little
protection; similarly, padding payloads to a fixed size exposes
information as payload sizes cross the fixed-sized boundary, which
could be possible if an attacker can control plaintext.
Paragraph (version B):
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.
Paragraph (version B):
As far as these create observable differences in behavior, they could
be used as a basis for fingerprinting a specific client.
Paragraph (version B):
HTTP/3's preference for using a single QUIC connection allows
correlation of a user's activity on a site.  Reusing connections for
different origins allows for correlation of activity across those
origins.
Paragraph (version B):
Several features of QUIC solicit immediate responses and can be used
by an endpoint to measure latency to their peer; this might have
privacy implications in certain scenarios.