Re: [secdir] Secdir review of draft-ietf-quic-qpack

[Magnus Nyström <[e-mail]>]

Correcting qpack ietf email address, sorry.

On Wed, Nov 18, 2020 at 9:59 PM Magnus Nyström <[e-mail]> wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
>
> This document describes a mechanism for compressing HTTP fields in the
> context of HTTP/3.
>
>    - The security considerations section is well written, but the attack
>    scenario of "mutual distrustful parties" is unclear to me. One stated
>    scenario is where multiple client connections aggregate at an intermediary
>    that then maintains a single connection to an origin server. Another stated
>    scenario is where multiple origin servers connect to an intermediary which
>    then serves a client. In these scenarios, is the concern that the
>    intermediary may control either a client or an origin server and thus would
>    be able to leverage the compression context at, say, a second client and
>    then observe (as the intermediary) the result of a guess for a field tuple?
>    It may be helpful to explain this in a little more detail.
>
>    While there are several options listed, there is also no
>    recommendation as to what strategy (option) implementations should choose
>    to protect against this attack. It seems like the Never-Indexed-Literal is
>    a good candidate which should be easy to implement.
>    - For Section 7.5, is it intended to communicate that an attacker will
>    not be able (based on no current known attack against static Huffman
>    encodings) to mount the previously described "probing" attack? If so,
>    adding a sentence at the end of the section along the lines of "Thus, the
>    previously mentioned probing attack is not known to be applicable for any
>    fields where static Huffman encoding is used."
>
> Thanks,
> -- Magnus
>