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