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
- [quicwg/base-drafts] Import HTTP/2 Security Consi… Mike Bishop
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… Mike Bishop
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… Martin Thomson
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… Mike Bishop
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… Mike Bishop
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… Mike Bishop
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… Mike Bishop
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… Lucas Pardue
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… Lucas Pardue
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… Mike Bishop
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… Mike Bishop
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… Lucas Pardue
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… ianswett
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… Mike Bishop
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… Mike Bishop
- Re: [quicwg/base-drafts] Import HTTP/2 Security C… Mike Bishop