Draft: draft-ietf-quic-qpack

Commentary: Behold 
 I think this is inches of getting landed 
 The full text of that section is " TBD . " 
 HPACK covers the following topics : Probing Dynamic Table State Static Huffman Encoding Memory Consumption / DoS Implementation Limits To what degree to we need to retread this vs referring to 7541 ? There are some new areas to cover related to DoS , like recommending implementation timeouts for blocking requests . Soliciting any other topics , and possibly a passionate security - minded volunteer to draft a PR . 
 All looks good ( and familiar ) ; some minor nits .
Paragraph (version A):
TBD.  Also see Section 7.1 of RFC7541.
Paragraph (version B):
Use of compression as a length-based oracle for verifying guesses
about secrets that are compressed into a shared compression
context.
Paragraph (version B):
Denial of service resulting from exhausting processing or memory
capacity at a decoder.
Paragraph (version B):
QPACK 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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
Attacks like CRIME CRIME demonstrated the existence of these general
attacker capabilities.  The specific attack exploited the fact that
DEFLATE RFC1951 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 linear-time attack.
Paragraph (version B):
QPACK mitigates but does not completely prevent attacks modeled on
CRIME 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.
Paragraph (version B):
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.
Paragraph (version B):
Attacks of this nature are possible any time that two mutually
distrustful entities control requests or responses that are placed
onto a single HTTP/3 connection.  If the shared QPACK compressor
permits one entity to add entries to the dynamic table, and the other
to access those entries, then the state of the table can be learned.
Paragraph (version B):
takes responses from multiple origin servers and places them on a
shared connection toward a client.
Paragraph (version B):
Web browsers also need to assume that requests made on the same
connection by different web origins RFC6454 are made by mutually
distrustful entities.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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 not being compared to
the dynamic table entries in future messages, effectively preventing
further guesses.
Paragraph (version B):
Simply removing entries corresponding to the header field from the
dynamic 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 dynamic table.
Paragraph (version B):
This response might be made inversely proportional to the length of
the header 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.
Paragraph (version B):
Implementations can also choose to protect sensitive header fields by
not compressing them and instead encoding their value as literals.
Paragraph (version B):
Refusing to insert a header field into the dynamic table is only
effective if doing so is avoided on all hops.  The never indexed
literal bit (see literal-name-reference) can be used to signal to
intermediaries that a particular value was intentionally sent as a
literal.
Paragraph (version B):
An intermediary MUST NOT re-encode a value that uses a literal
representation with the 'N' bit set with another representation that
would index it.  If QPACK is used for re-encoding, a literal
representation with the 'N' bit set MUST be used.  If HPACK is used
for re-encoding, the never indexed literal representation (see
Section 6.2.3 of RFC7541) MUST be used.
Paragraph (version B):
The choice to mark that a header field should never be indexed
depends on several factors.  Since QPACK doesn't protect against
guessing an entire header field value, short or low-entropy values
are more readily recovered by an adversary.  Therefore, an encoder
might choose not to index values with low entropy.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
Note that these criteria for deciding to use a never indexed literal
representation will evolve over time as new attacks are discovered.
Paragraph (version B):
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).
Paragraph (version B):
An attacker can try to cause an endpoint to exhaust its memory.
QPACK is designed to limit both the peak and stable amounts of memory
allocated by an endpoint.
Paragraph (version B):
The amount of memory used by the encoder 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 settings parameters
SETTINGS_QPACK_MAX_TABLE_CAPACITY and SETTINGS_QPACK_BLOCKED_STREAMS,
respectively (see maximum-dynamic-table-capacity and blocked-
streams).  The limit on the size of the dynamic table takes into
account 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.
Paragraph (version B):
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 SETTINGS_QPACK_MAX_TABLE_CAPACITY parameter.  An
encoder can limit the amount of state memory it uses by signaling a
lower dynamic table size than the decoder allows (see eviction).
Paragraph (version B):
A decoder can limit the amount of state memory used for blocked
streams by setting an appropriate value for the maximum number of
blocked streams.  In HTTP/3, this is realized by setting an
appropriate value for the QPACK_BLOCKED_STREAMS parameter.  An
encoder can limit the amount of state memory by only using as many
blocked streams as it wishes to support; no signaling to the decoder
is requred.
Paragraph (version B):
The amount of temporary memory consumed by an encoder or decoder can
be limited by processing header fields sequentially.  A decoder
implementation does not need to retain a complete list of header
fields while decoding a header block.  An encoder implementation does
not need to retain a complete list of header fields while encoding a
header block if it is using a single-pass algorithm.  Note that it
might be necessary for an application to retain a complete header
list for other reasons; even if QPACK does not force this to occur,
application constraints might make this necessary.
Paragraph (version B):
An implementation of QPACK needs to ensure that large values for
integers, long encoding for integers, or long string literals do not
create security weaknesses.
Paragraph (version B):
An implementation has to set a limit for the values it accepts for
integers, as well as for the encoded length (see prefixed-integers).
In the same way, it has to set a limit to the length it accepts for
string literals (see string-literals).