Code change:
8. <ins> This section describes potential areas of security concern with HPACK: Use of compression as a length-based oracle for verifying guesses about secrets that are compressed into a shared compression context. Denial of service resulting from exhausting processing or memory capacity at a decompressor. </ins> 8.1. <del> Compression can create a weak point allowing an attacker to recover secret data.  For example, the CRIME attack (see CRIME) took advantage of the DEFLATE mechanism (see DEFLATE) of SPDY (see SPDY) to efficiently probe the compression context.  The full-text compression mechanism of DEFLATE allowed the attacker to learn some information from each failed attempt at guessing the secret. For this reason, HPACK provides only limited compression mechanisms in the form of an indexing table and of a static Huffman encoding. The indexing table can still provide information to an attacker that would be able to probe the compression context.  However, this information is limited to the knowledge of whether the attacker's guess is correct or not. Still, an attacker could take advantage of this limited information for breaking low-entropy secrets using a brute-force attack.  A server usually has some protections against such brute-force attack. Here, the attack would target the client, where it would be harder to detect.  The attack would be even more dangerous if the attacker is able to prevent the traffic generated by its brute-force attack from reaching the server. To offer some protection against such type of attacks, HPACK enables an endpoint to indicate that a header field must never be compressed, across any hop up to the other endpoint (see literal.header.never.indexed).  An endpoint MUST use this feature to prevent the compression of any header field whose value contains a secret which could be put at risk by a brute-force attack. For optimal processing, a sensitive value (for example a cookie) needs to have an entropy high enough to not be endangered by a brute- force attack, in order to take advantage of HPACK indexing. </del> <ins> HPACK reduces the length of header field encodings by exploiting the redundancy inherent in protocols like HTTP.  The ultimate goal of this is to reduce the amount of data that is required to send HTTP requests or responses. The header table that HPACK uses can be probed by an attacker that has the following capabilities: to encode and transmit header fields; and to observe the length of those fields as they are encoded.  The allows an attacker to adaptively modify requests in order to confirm guesses about the header table state.  If the HPACK encoder compresses a guess into a shorter length, the attacker can observe the encoded length and infer that the guess was correct. This is possible because while TLS provides confidentiality protection for content, it only provides a limited amount of protection for the length of that content. Padding schemes only provide limited protection against an attacker with these capabilities, potentially only forcing an increased number of guesses to learn the length associated with a given guess.  Padding schemes also work directly against compression by increasing the number of bits that are transmitted. Attacks like CRIME demonstrated the existence of these general attacker capabilities.  The specific attack exploited the fact that DEFLATE removes redundancy based on prefix matching.  This permitted the attacker to confirm guesses a character at a time, reducing an exponential-time attack into a constant time attack. 8.1.1. HPACK mitigates but does not completely prevent attacks modelled on CRIME by forcing a guess to match an entire header field value, rather than individual characters.  An attacker can only learn whether a guess is correct or not, so is reduced to a brute force guess for the header field values. The viability of recovering specific header field values therefore depends on the entropy of values.  As a result, values with high entropy are unlikely to be recovered successfully.  However, values with low entropy remain vulnerable. Attacks of this nature are possible any time that two mutually distrustful entities control requests or responses that are placed onto a single HTTP/2 connection.  If the shared HPACK compressor permits one entity to add entries to the header table, and the other to access those entries, then the state of the table can be learned. Having requests or responses from mutually distrustful entities occurs when an intermediary either: sends requests from multiple clients on a single connection toward an origin server, or takes responses from multiple origin servers and places them on a shared connection toward a client. Web browsers also need to assume that requests made on the same connection by different ORIGIN are made by mutually distrustful entities. Assuming no additional constraints, multiplexing in HTTP/2 enables multiple attempts to guess values from the header table, up to the concurrency limit imposed by the peer in the SETTINGS_MAX_CONCURRENT_STREAMS setting.  This depends on the attacker being on the communications path so that they are able to see and block packets.  Beyond this limit, or for an entirely passive attacker, attempts to guess header table state can be detected by a peer. 8.1.2. 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 HPACK can instead constrain how compression is applied in order to limit the potential for header table probing. An ideal solution segregates access to the header 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 an particular value can extract that value. 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 encoder without good knowledge of the provenance of header fields might instead introduce a penalty for bad guesses, such that attempts to guess a header field value results in all values being removed from consideration in all future requests, effectively preventing further guesses. Simply removing values from the header table can be ineffectual if the attacker has a reliable way of causing values to be reinstalled.  For example, a request to load an image in a web browser typically includes the Cookie header field (a potentially highly valued target for this sort of attack), and web sites can easily force an image to be loaded, thereby refreshing the entry in the header table. This response might be made inversely proportional to the length of the header field.  Marking as inaccessible might occur for shorter values more quickly or with higher probability than for longer values. Implementations might also choose to protect certain header fields that are known to be highly valued, such as the Authorization or Cookie header fields, by disabling or further limiting compression. 8.1.3. Refusing to generate an indexed representation for a header field is only effective if compression is avoided on all hops.  The literal.header.never.indexed can be used to signal to intermediaries that a particular value was intentionally sent as a literal.  An intermediary MUST NOT re-encode a value that uses the never indexed literal as an indexed representation. 8.2. </ins> There is currently no known threat taking advantage of the use of a fixed Huffman encoding.  A study has shown that using a fixed Huffman

Related discussion:
text: I have written what I think is a slightly more robust Security Consideration for HPACK. This covers: the attack in the general sense, how the attack might apply in HPACK and HTTP, particular areas of concern, how HPACK inherently mitigates these attacks, what environments might need additional mitigation, and some suggested mitigation strategies. Mitigation strategies that I have described are: actor-based isolation (a generalized application of the origin isolation principle) destroy values on failed guesses (thanks here to Adam Barth for the idea), either probabilistically, or based on a count, with a recommendation that shorter values be made harder to guess specific protection for "special" header fields There are a few formatting changes in the first commit, sorry.