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

[Mike Bishop <[e-mail]>]

@MikeBishop approved this pull request.

All looks good (and familiar); some minor nits.

> +used.  If HPACK (see Section 6.2.3 of [RFC7541]) is used for re-encoding, the
+never indexed literal representation MUST be used.

```suggestion
used.  If HPACK is used for re-encoding, the never indexed literal
representation (see Section 6.2.3 of [RFC7541]) MUST be used.
```

> +
+Implementations can also choose to protect sensitive header fields by not
+compressing them and instead encoding their value as literals.
+
+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.
+
+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 (see Section 6.2.3 of [RFC7541]) is used for re-encoding, the
+never indexed literal representation MUST be used.
+
+The choice to use a never indexed literal representation for a header field

```suggestion
The choice to mark that a header field should never be indexed
```

> +the decoder through the setting parameter SETTINGS_QPACK_MAX_TABLE_CAPACITY and
+SETTINGS_QPACK_BLOCKED_STREAMS, respectively (see

```suggestion
the decoder through the settings parameters SETTINGS_QPACK_MAX_TABLE_CAPACITY
and SETTINGS_QPACK_BLOCKED_STREAMS, respectively (see
```

> +
+## 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]).
+
+## Memory Consumption
+
+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.
+
+The amount of memory used by the compressor is limited by the protocol using

```suggestion
The amount of memory used by the encoder is limited by the protocol using
```

> +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}}).
+
+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.
+
+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
+if while encoding a header block if it is using a single-pass encoder.  Note

```suggestion
while encoding a header block if it is using a single-pass algorithm.  Note
```

> @@ -1155,6 +1369,19 @@ to an excess of unsent data might include limiting the ability of the peer to
 open new streams, reading only from the encoder stream, or closing the
 connection.
 
+
+## Implementation Limits
+
+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.
+
+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}}).

I believe we have a minimum size which MUST be supported; should that be mentioned here?

-- 
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-394965096