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

Martin Thomson <notifications@github.com> Wed, 18 March 2020 22:01 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C8E3A1D12 for <quic-issues@ietfa.amsl.com>; Wed, 18 Mar 2020 15:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Level:
X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjp4ibIhpOvA for <quic-issues@ietfa.amsl.com>; Wed, 18 Mar 2020 15:01:25 -0700 (PDT)
Received: from out-21.smtp.github.com (out-21.smtp.github.com [192.30.252.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39423A1D11 for <quic-issues@ietf.org>; Wed, 18 Mar 2020 15:01:24 -0700 (PDT)
Received: from github-lowworker-d93c4b6.va3-iad.github.net (github-lowworker-d93c4b6.va3-iad.github.net [10.48.17.47]) by smtp.github.com (Postfix) with ESMTP id 0F9C5A0DF8 for <quic-issues@ietf.org>; Wed, 18 Mar 2020 15:01:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584568884; bh=BPDhTF2irQaYmNpr99t1wXrkXYQacxxiBjF4BR/Pmf8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=appP7RUmpQp/w0O1ALcCCXannW1GVPPczLvKMmgkVGxxlg9s1uMzbV5zwAbZWIpFV H9PPYbsHiWMupwZhOWjfK4bau06+Eazl+2TcnvQXMTNoubO+2YmIlRNpTNCvxFBf7t xj49JHOfLWdpidl0mr/Zle5KvJiy4qVb2s5zmn6o=
Date: Wed, 18 Mar 2020 15:01:24 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4KIOFAR4CVEMC62BV4PZ5THEVBNHHCFTHBIQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3531/review/377210304@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3531@github.com>
References: <quicwg/base-drafts/pull/3531@github.com>
Subject: Re: [quicwg/base-drafts] Import HTTP/2 Security Considerations (#3531)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e729a33f3fb4_1df23f819a4cd960169514"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/PFU4opypbTFk_Aua1d9ESGD5lEY>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2020 22:01:28 -0000

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