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

From: Magnus Nyström <[email-masked]>
Date: Wed, 18 Nov 2020 21:59:50 -0800

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

---

From: Magnus Nyström <[email-masked]>
Date: Wed, 18 Nov 2020 22:14:54 -0800

Correcting qpack ietf email address, sorry.

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

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