Subject: [quicwg/base-drafts] Import HTTP/2 Security Considerations (#3531)

From: Mike Bishop <[email-masked]>
Date: Wed, 18 Mar 2020 09:27:58 -0700

The follow-on to #3407; depends on #3513.  **DO NOT MERGE** before #3513 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.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3531

-- Commit Summary --

  * Import H2 Security Considerations

-- File Changes --

    M draft-ietf-quic-http.md (205)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3531.patch
https://github.com/quicwg/base-drafts/pull/3531.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531

---

From: Mike Bishop <[email-masked]>
Date: Wed, 18 Mar 2020 09:33:06 -0700

@MikeBishop pushed 2 commits.

ae28bd57ca122fffe9930c2b46887f4198169c46  Wrapping
1f324810d8e2b513e587b897b5d5a531b841b3fe  URL reference format

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531/files/ab4e7ca3b82885a05ce7c894ec856c1e9684775b..1f324810d8e2b513e587b897b5d5a531b841b3fe

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Mar 2020 15:01:24 -0700

martinthomson approved this pull request.

Looks good to me.  Thanks for doing the hard work here.

> +of establishing authority are discussed in Section 11.1 of {{!SEMANTICS}}.
+
+## Cross-Protocol Attacks
+
+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
+attack on a plaintext protocol.
+
+## 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 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

```suggestion
({{malformed}}).  An intermediary therefore cannot translate an HTTP/3 request or
```

> +of establishing authority are discussed in Section 11.1 of {{!SEMANTICS}}.
+
+## Cross-Protocol Attacks
+
+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
+attack on a plaintext protocol.
+
+## 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 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

MUST NOT instead of cannot?

> +
+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.
+
+Processing capacity cannot be guarded as effectively as state capacity.
+
+The ability to send undefined protocol elements which 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
+legitimate, such as optional-to-understand extensions and padding to increase
+resistance to traffic analysis.
+
+Header compression also offers some opportunities to waste processing resources;
+see Section 7 of {{!QPACK} for more details on potential abuses.

```suggestion
see Section 7 of {{!QPACK}} for more details on potential abuses.
```

> +Pushed responses for which an origin server is not authoritative (see
+{{connection-reuse}}) MUST NOT be used or cached.

```suggestion
Pushed responses for which an origin server is not authoritative MUST NOT
be used or cached; see {{connection-reuse}}.
```

> +
+## 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 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.
+
+Similarly, HTTP/3 allows header field values that are not valid. While most of
+the values that can be encoded will not alter header 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 header
+field value MUST be treated as malformed ({{malformed}}).  Valid characters are
+defined by the "field-content" ABNF rule in 4.4 of {{!SEMANTICS}}.

```suggestion
defined by the "field-content" ABNF rule in Section 4.4 of {{!SEMANTICS}}.
```

> +might be done by setting multiple undefined SETTINGS parameters, unknown frame
+types, or unknown stream types.  Note, however, that some uses are entirely
+legitimate, such as optional-to-understand extensions and padding to increase
+resistance to traffic analysis.
+
+Header compression also offers some opportunities to waste processing resources;
+see Section 7 of {{!QPACK} for more details on potential abuses.
+
+All these features -- i.e., server push, unknown protocol elements, header
+compression -- have legitimate uses.  These features become a burden only when
+they are used unnecessarily or to excess.
+
+An endpoint that doesn't monitor this 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.  An endpoint MAY treat activity that is
+suspicious as a connection error ({{errors}) of type H3_EXCESSIVE_LOAD.

```suggestion
suspicious as a connection error ({{errors}}) of type H3_EXCESSIVE_LOAD.
```

> +denial-of-service attack.  Implementations SHOULD track the use of these
+features and set limits on their use.  An endpoint MAY treat activity that is
+suspicious as a connection error ({{errors}) of type H3_EXCESSIVE_LOAD.
+
+### Limits on Field Section Size
+
+A large field section ({{request-response}}) can cause an implementation to
+commit a large amount of state.  Header fields that are critical for routing can
+appear toward the end of a header field section, which prevents streaming of the
+header field section to its ultimate destination.  This ordering and other
+reasons, such as ensuring cache correctness, mean that an endpoint might need to
+buffer the entire header field section.  Since there is no hard limit to the
+size of a field section, some endpoints could be forced to commit a large amount
+of available memory for header fields.
+
+An endpoint can use the SETTINGS_MAX_HEADER_LIST_SIZE ({{settings-parameters}})

Name check here.

> +### CONNECT Issues
+
+The CONNECT method can be used to create disproportionate load on an proxy,
+since stream creation is relatively inexpensive when compared to the creation
+and maintenance of a TCP connection.  A proxy might also maintain some resources
+for a TCP connection beyond the closing of the stream that carries the CONNECT
+request, since the outgoing TCP connection remains in the TIME_WAIT state.
+Therefore, a proxy cannot rely on QUIC stream limits alone to control the
+resources consumed by CONNECT requests.
+
+## 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/2 enables compression
+of fields ({{header-formatting}}); the following concerns also apply to the use
+of HTTP compressed content- codings (Section 6.1.2 of {{!SEMANTICS}}).

```suggestion
of HTTP compressed content-codings; see Section 6.1.2 of {{!SEMANTICS}}.
```

> +client can discard responses that it cannot process.
+
+### CONNECT Issues
+
+The CONNECT method can be used to create disproportionate load on an proxy,
+since stream creation is relatively inexpensive when compared to the creation
+and maintenance of a TCP connection.  A proxy might also maintain some resources
+for a TCP connection beyond the closing of the stream that carries the CONNECT
+request, since the outgoing TCP connection remains in the TIME_WAIT state.
+Therefore, a proxy cannot rely on QUIC stream limits alone to control the
+resources consumed by CONNECT requests.
+
+## 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/2 enables compression

```suggestion
in the same context as data under attacker control. HTTP/3 enables compression
```

> +since stream creation is relatively inexpensive when compared to the creation
+and maintenance of a TCP connection.  A proxy might also maintain some resources
+for a TCP connection beyond the closing of the stream that carries the CONNECT
+request, since the outgoing TCP connection remains in the TIME_WAIT state.
+Therefore, a proxy cannot rely on QUIC stream limits alone to control the
+resources consumed by CONNECT requests.
+
+## 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/2 enables compression
+of fields ({{header-formatting}}); the following concerns also apply to the use
+of HTTP compressed content- codings (Section 6.1.2 of {{!SEMANTICS}}).
+
+There are demonstrable attacks on compression that exploit the characteristics
+of the web (e.g., [BREACH]).  The attacker induces multiple requests containing

Maybe be consistent...
```suggestion
of the web (e.g., {{BREACH}}).  The attacker induces multiple requests containing
```

> +in the same context as data under attacker control. HTTP/2 enables compression
+of fields ({{header-formatting}}); the following concerns also apply to the use
+of HTTP compressed content- codings (Section 6.1.2 of {{!SEMANTICS}}).
+
+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.
+
+Implementations communicating on a secure channel MUST NOT compress content that
+includes both confidential and attacker-controlled data unless separate
+compression dictionaries are used for each source of data.  Compression MUST NOT
+be used if the source of data cannot be reliably determined.
+
+Further considerations regarding the compression of header fields are
+described in [QPACK].

```suggestion
described in {{QPACK}}.
```

> +which reveals a shorter length when a guess about the secret is correct.
+
+Implementations communicating on a secure channel MUST NOT compress content that
+includes both confidential and attacker-controlled data unless separate
+compression dictionaries are used for each source of data.  Compression MUST NOT
+be used if the source of data cannot be reliably determined.
+
+Further considerations regarding the compression of header fields are
+described in [QPACK].
+
+## 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, for example, attacks where compressed
+content includes both attacker-controlled plaintext and secret data (e.g.,
+[BREACH]).

```suggestion
{{BREACH}}).
```

> @@ -1722,6 +1881,23 @@ addresses), such implementations will need to either actively retrieve the
 client's current address or addresses when they are relevant or explicitly
 accept that the original address might change.
 
+## 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.
+
+As far as these create observable differences in behavior, they could be used as
+a basis for fingerprinting a specific client.
+
+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
+tracking across those origins.

```suggestion
for correlation of activity across those origins.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531#pullrequestreview-377210304

---

From: Mike Bishop <[email-masked]>
Date: Thu, 19 Mar 2020 05:37:08 -0700

MikeBishop commented on this pull request.

If this were pointing to an expanded description of handling pushed responses, I think that would be the right arrangement.  This is pointing specifically to a discussion of when a server is authoritative.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531#discussion_r394993455

---

From: Mike Bishop <[email-masked]>
Date: Thu, 19 Mar 2020 05:42:15 -0700

@MikeBishop pushed 1 commit.

b53aa88fe335490604dc6e51e73d36e55c3c0360  Apply suggestions from code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531/files/1f324810d8e2b513e587b897b5d5a531b841b3fe..b53aa88fe335490604dc6e51e73d36e55c3c0360

---

From: Mike Bishop <[email-masked]>
Date: Thu, 19 Mar 2020 05:42:31 -0700

+

I don't think this is a new restriction; it's a statement about the ramifications of a compliant implementation.  If you follow the previous MUST NOT, the ramification is that you cannot produce an invalid HTTP/1.1 request from an HTTP/3 request.

Seems to be up-to-date for now, though we might want to change it per #3452.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531#discussion_r394994403

---

From: Mike Bishop <[email-masked]>
Date: Thu, 19 Mar 2020 05:47:02 -0700

fd258e3ee78166f78bf22a3b4d3d2bf2aa5e6190  No, this was correct

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531/files/b53aa88fe335490604dc6e51e73d36e55c3c0360..fd258e3ee78166f78bf22a3b4d3d2bf2aa5e6190

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 19 Mar 2020 10:44:08 -0700

LPardue commented on this pull request.

+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.
+
+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.
+
+Pushed responses for which an origin server is not authoritative (see
+{{connection-reuse}}) MUST NOT be used or cached.
+
+## Denial-of-Service Considerations

Is it worth a link to the HTTP/2 DoS CVE(s) from 2019 as a practical demonstration?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531#pullrequestreview-377953197

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 19 Mar 2020 10:52:13 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531#issuecomment-601325366

---

From: Mike Bishop <[email-masked]>
Date: Thu, 19 Mar 2020 13:42:36 -0700

Given the chain, this PR *should* consistently use the new terminology.  If I missed something, please flag it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531#issuecomment-601406818

---

From: Mike Bishop <[email-masked]>
Date: Thu, 19 Mar 2020 13:46:49 -0700

85d2f9d57313304d064ca0f9abe2da0437c5cd50  Fields, again

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531/files/fd258e3ee78166f78bf22a3b4d3d2bf2aa5e6190..85d2f9d57313304d064ca0f9abe2da0437c5cd50

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 20 Mar 2020 10:40:46 -0700

@MikeBishop these comments/suggestion address my earlier one about use of headers. I might be applying things wrong.

> +- the inclusion of uppercase header field names, or
+- the inclusion of invalid characters in header field names or values

```suggestion
- the inclusion of uppercase field names, or
- the inclusion of invalid characters in field names or values
```

> +features are strictly bounded.
+

Is it still called "header compression" in a post-header world?

> +A server that receives a larger header block than it is willing to handle can
+send an HTTP 431 (Request Header Fields Too Large) status code {{?RFC6585}}.  A
+client can discard responses that it cannot process.

Is this behaviour restricted to encoded blocks of Header field sections? Could a large trailer section trigger it?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531#pullrequestreview-378680616

---

From: ianswett <[email-masked]>
Date: Sat, 21 Mar 2020 12:39:59 -0700

ianswett commented on this pull request.

+An HTTP/3 connection can demand a greater commitment of resources to operate

I'm not sure I know why this would be true, particularly for HTTP/2 vs HTTP/3?

+types, or unknown stream types.  Note, however, that some uses are entirely
+legitimate, such as optional-to-understand extensions and padding to increase
+resistance to traffic analysis.
+
+Header compression also offers some opportunities to waste processing resources;
+see Section 7 of [QPACK] for more details on potential abuses.
+
+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.
+
+An endpoint that doesn't monitor this 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.  An endpoint MAY treat activity that is
+suspicious as a connection error ({{errors}}) of type H3_EXCESSIVE_LOAD.

It might be worth calling out that this could close valid connections and cause requests to fail?

> +All these features -- i.e., server push, unknown protocol elements, field
+suspicious as a connection error ({{errors}}) of type H3_EXCESSIVE_LOAD.

In my experience, this is quite likely a requirement, not just a might.  So I'd be inclined to make this stronger(ie: "likely needs to..."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531#pullrequestreview-378944999

---

From: Mike Bishop <[email-masked]>
Date: Wed, 25 Mar 2020 13:03:05 -0700

@MikeBishop commented on this pull request.

Some implementations still experience higher resource usage for HTTP/3 for various reasons (lack of hardware offload, smaller encryption units, UDP less optimized than TCP, etc.).  While I hope that some of those things will change over time and the rest will matter less, I think it's still a generally true statement that HTTP/3 **can** demand greater resources.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531#discussion_r398133513

---

From: Mike Bishop <[email-masked]>
Date: Thu, 26 Mar 2020 08:34:25 -0700

d7c2d2ee3e301d47709db2cf5e1edfe26ff2c46c  Review feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531/files/85d2f9d57313304d064ca0f9abe2da0437c5cd50..d7c2d2ee3e301d47709db2cf5e1edfe26ff2c46c

---

From: Mike Bishop <[email-masked]>
Date: Mon, 30 Mar 2020 08:59:22 -0700

Merged #3531 into master.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3531#event-3179337815