Last Call Review of draft-ietf-quic-qpack-19
review-ietf-quic-qpack-19-secdir-lc-nystrom-2020-11-19-00

 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