Re: [quicwg/base-drafts] QPACK security considerations (#3575)

Martin Thomson <notifications@github.com> Tue, 14 April 2020 01:16 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 7F3E33A2291 for <quic-issues@ietfa.amsl.com>; Mon, 13 Apr 2020 18:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.267
X-Spam-Level:
X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, 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 H9aQckaccNHu for <quic-issues@ietfa.amsl.com>; Mon, 13 Apr 2020 18:16:47 -0700 (PDT)
Received: from out-26.smtp.github.com (out-26.smtp.github.com [192.30.252.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACAB23A2290 for <quic-issues@ietf.org>; Mon, 13 Apr 2020 18:16:47 -0700 (PDT)
Received: from github-lowworker-5825cd4.ac4-iad.github.net (github-lowworker-5825cd4.ac4-iad.github.net [10.52.22.68]) by smtp.github.com (Postfix) with ESMTP id 83C80282B8A for <quic-issues@ietf.org>; Mon, 13 Apr 2020 18:16:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1586827006; bh=Ei1ic4Y3GX+5bSSXaTnx1dZUwHnYOcQkfZU30OyZgOM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=wZuGtMS7QQ1u0uHVLvay0pevHqkSsmM9SkcTwVMX5lRQviZWG5tK0Ie6QFroHwXoH aln+39LncyLqQa4NNJmjOj+FkGhzbMbyUktWO6mAUyHLblyfRyFD01G8Bp+elSrqB9 klfU0vZWakqAM+kwBYYGhtb8fHmbPQUArCaV6sUA=
Date: Mon, 13 Apr 2020 18:16:46 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3V4NQVO3ZPYVQM3BF4UDX75EVBNHHCHNTZ2Y@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3575/review/392536154@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3575@github.com>
References: <quicwg/base-drafts/pull/3575@github.com>
Subject: Re: [quicwg/base-drafts] QPACK security considerations (#3575)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e950efe7236c_699b3ff3528cd96490223"; 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/HvmRaRX9UeGaEq7fomrmK53dI-o>
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: Tue, 14 Apr 2020 01:16:51 -0000

@martinthomson approved this pull request.

This looks good.  But then I'm not impartial in this.

An informative reference to HPACK might be wise.  Otherwise people might get an unexplained sense of déjà vu.

> +
+The compression context used to encode header fields can be probed by an
+attacker who can both define header fields to be encoded and transmitted and
+observe the length of those fields once they are encoded. When an attacker can
+do both, they can adaptively modify requests in order to confirm guesses about
+the dynamic table state. If a guess is compressed into a shorter length, the
+attacker can observe the encoded length and infer that the guess was correct.
+
+This is possible even over the Transport Layer Security Protocol (TLS, see
+{{?RFC5246}}), because while TLS provides confidentiality protection for
+content, it only provides a limited amount of protection for the length of that
+content.
+
+Note:
+
+Padding schemes only provide limited protection against an attacker with these

```suggestion
: Padding schemes only provide limited protection against an attacker with these
```

> +
+Users of HTTP that require confidentiality for header fields can use values with
+entropy sufficient to make guessing infeasible. However, this is impractical as
+a general solution because it forces all users of HTTP to take steps to mitigate
+attacks. It would impose new constraints on how HTTP is used.
+
+Rather than impose constraints on users of HTTP, an implementation of QPACK can
+instead constrain how compression is applied in order to limit the potential for
+dynamic table probing.
+
+An ideal solution segregates access to the dynamic table based on the entity
+that is constructing header fields. Header field values that are added to the
+table are attributed to an entity, and only the entity that created a particular
+value can extract that value.
+
+To improve compression performance of tqhis option, certain entries might be tagged as being public. For example, a web browser might make the values of the Accept-Encoding header field available in all requests.

```suggestion
To improve compression performance of this option, certain entries might be
tagged as being public. For example, a web browser might make the values of the
Accept-Encoding header field available in all requests.
```

> +An ideal solution segregates access to the dynamic table based on the entity
+that is constructing header fields. Header field values that are added to the
+table are attributed to an entity, and only the entity that created a particular
+value can extract that value.
+
+To improve compression performance of tqhis option, certain entries might be tagged as being public. For example, a web browser might make the values of the Accept-Encoding header field available in all requests.
+
+An encoder without good knowledge of the provenance of header fields might
+instead introduce a penalty for a header field with many different values, such
+that a large number of attempts to guess a header field value results in the
+header field no more being compared to the dynamic table entries in future
+messages, effectively preventing further guesses.
+
+Note:
+
+Simply removing entries corresponding to the header field from the dynamic table

```suggestion
: Simply removing entries corresponding to the header field from the dynamic table
```

> +that a large number of attempts to guess a header field value results in the
+header field no more being compared to the dynamic table entries in future
+messages, effectively preventing further guesses.

```suggestion
that a large number of attempts to guess a header field value results in the
header field not being compared to the dynamic table entries in future
messages, effectively preventing further guesses.
```

I had a little trouble with "no more".

> +field value. Marking a header field as not using the dynamic table any more
+might occur for shorter values more quickly or with higher probability than for
+longer values.

```suggestion
field value. Disabling access to the dynamic table for a header field might
occur for shorter values more quickly or with higher probability than for longer
values.
```

> +values with low entropy.
+
+An encoder might also choose not to index values for header fields that are
+considered to be highly valuable or sensitive to recovery, such as the Cookie or
+Authorization header fields.
+
+On the contrary, an encoder might prefer indexing values for header fields that
+have little or no value if they were exposed. For instance, a User-Agent header
+field does not commonly vary between requests and is sent to any server. In that
+case, confirmation that a particular User-Agent value has been used provides
+little value.
+
+Note that these criteria for deciding to use a never indexed literal
+representation will evolve over time as new attacks are discovered.
+
+##. Static Huffman Encoding

```suggestion
## Static Huffman Encoding
```

> +On the contrary, an encoder might prefer indexing values for header fields that
+have little or no value if they were exposed. For instance, a User-Agent header
+field does not commonly vary between requests and is sent to any server. In that
+case, confirmation that a particular User-Agent value has been used provides
+little value.
+
+Note that these criteria for deciding to use a never indexed literal
+representation will evolve over time as new attacks are discovered.
+
+##. Static Huffman Encoding
+
+There is no currently known attack against a static Huffman encoding. A study
+has shown that using a static Huffman encoding table created an information
+leakage, however this same study concluded that an attacker could not take
+advantage of this information leakage to recover any meaningful amount of
+information (see [PETAL]).

Want to point out that QPACK uses the same Huffman table as HPACK?

> +designed to limit both the peak and state amounts of memory allocated by an
+endpoint.

```suggestion
designed to limit both the peak and stable amounts of memory allocated by an
endpoint.
```

> +has shown that using a static Huffman encoding table created an information
+leakage, however this same study concluded that an attacker could not take
+advantage of this information leakage to recover any meaningful amount of
+information (see [PETAL]).
+
+## Memory Consumption
+
+An attacker can try to cause an endpoint to exhaust its memory. QPACK is
+designed to limit both the peak and state amounts of memory allocated by an
+endpoint.
+
+The amount of memory used by the compressor is limited by the protocol using
+QPACK through the definition of the maximum size of the dynamic table, and the
+maximum number of blocking streams. In HTTP/3, these values are controlled by
+the decoder through the setting parameter QPACK_MAX_TABLE_CAPACITY and
+QPACK_BLOCKED_STREAMS, respectively (see Section

```suggestion
QPACK_BLOCKED_STREAMS, respectively (see
```

> +maximum number of blocking streams. In HTTP/3, these values are controlled by
+the decoder through the setting parameter QPACK_MAX_TABLE_CAPACITY and
+QPACK_BLOCKED_STREAMS, respectively (see Section
+{{maximum-dynamic-table-capacity}} and {{blocked-streams}}). The limit on the
+size of the dynamic table takes into account both the size of the data stored in
+the dynamic table, plus a small allowance for overhead.  The limit on the number
+of blocked streams is only a proxy for the maximum amount of memory required by
+the decoder.  The actual maximum amount of memory will depend on how much memory
+the decoder uses to track each blocked stream.
+
+A decoder can limit the amount of state memory used for the dynamic table by
+setting an appropriate value for the maximum size of the dynamic table. In
+HTTP/3, this is realized by setting an appropriate value for the
+QPACK_MAX_TABLE_CAPACITY parameter. An encoder can limit the amount of state
+memory it uses by signaling lower dynamic table size than the decoder allows
+(see {{eviction}}).  A decoder can limit the amount of state memory used for

```suggestion
(see {{eviction}}).

A decoder can limit the amount of state memory used for
```

-- 
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/3575#pullrequestreview-392536154