Review of draft-handte-httpbis-dict-sec-00

["Martin Thomson" <[e-mail]>]

I have to say that I found this to be quite an impressive start.  Thanks for putting this draft together.  It does a good job of laying out the terms of reference from the outset then it thoroughly addresses the angles.  It is perhaps *too* thorough, but I appreciate that cutting content is quite difficult in practice.

While I found this to be a reasonable survey of the problem space, I found the suggested mitigations to be less satisfactory on the whole.  This is a really solid start on explaining the sorts of security problems that compression introduces, but the mitigations are still too abstract for me to be comfortable with them.  For instance, the document suggests that padding compressed content might help, but it isn't clear to me to what extent size reductions would need to be eliminated by padding to gain any sort of confidence that the side channel could be removed.  Then I might concern myself with the degree to which the resulting timing side channel remains.

The key problem I'm interested in here is how we might go from an analysis of the problems (for which this is a great contribution) to actionable advice to people looking to deploy compression.  I appreciate that this is hard and this might need to be an iterative process.  In that spirit, I note that the document makes multiple references to Cloudflares "don't compress" flag.  I suspect that there is some value in standardized origin-to-CDN signals for "this contains a secret".  That might be a small step toward generating better understanding of the composition of content, which is what I think is ultimately what is needed in this area.

# Scope

At the top, I have to say that this analysis might be better framed as a generic analysis of compression.  In reading this, I concluded that dictionaries don't fundamentally change the nature of the problem.  Static dictionaries (such as those built into Brotli) don't change the strict interpretation of a compressor as a pure function.  Dynamic dictionaries are worth examining as they change is the set of inputs that the compressor/decompressor deals with, but this is a problem we might need to grapple with anyway.  

Even if we don't compress bundles of diverse content (see the web packaging work), or compress across multiple resources (as in Vlad's proposal) we have to recognize that formats like HTML naturally include content from diverse sources.  To think of this in a less positive light: use of compression is already highly suspect.  You basically say this in Section 2.4 already.  You can read that two ways: by recognizing that we're already in trouble, we might justify adding dictionaries on the basis that they don't make things appreciable worse; or - as I have - as a suggestion that we need to better understand and control how compression is used in general.

To that end, I think that some reworking of focus could help make this a more generally useful analysis.   That probably means trimming some of the extra content about dictionaries from Section 3 and creating a broader framing.  There are some dictionary-specific considerations at play here - such as those that relate to selection, construction, and acquisition - but I think that the main concerns are still those about content of mixed origin.

# Threat Model

Section 2.1 sets out the target for analysis, which I think is generally reasonable.  I would, however, caution against the implied assumption about "user action".  This seems to be saying that actions initiated by users are not in scope for analysis.  I realize that there are always cases where the safeties need to be disabled in pursuit of a particular goal, but I wouldn't frame this exactly this way.  It seems to me that the important point here is that protocol actions are sometimes taken in response to events controlled by external, possibly untrusted actors AND that the content of messages involved does not always originate from a trustworthy source.

That puts a lot more weight on the notion of "trust", which I think might be worth either expanding a little or being careful to avoid.  For instance, rather than saying "agents exchange messages with parties they may not trust", you might instead say that messages might be constructed by entities that could be malicious (or have ill intent toward recipients).  When you look at this from the perspective of content that the agent doesn't control, it might help better frame one of the primary motivators of the document: messages might contain a mix of content from mutually adversarial entities or entities that are adversarial toward the agent itself.

Part of what this is driving at is that there are new classes of security consideration that derive from a) the content of messages and its composition, b) the interaction of that content with the compression scheme, and c) the resulting side channels that arise.

In thinking about this, I can see why Section 2.3 (Threat Model) is still empty.  The scope of the task that this sets out is amazingly broad.  If we take the terms of reference from Section 2.1 without further qualification, the outcome might be obvious: don't compress because it is not generically safe.  That's the conclusion we drew with TLS, for instance.

I think that the stated goal is right though: the idea is to provide tools that help us recognize where compression is safe or not.

# Risks and Mitigations

There are a bunch of things here that depend on the threat model, so it's hard to be sure where we stand.  For instance, Section 4.2 talks about secret dictionaries.  Those are certainly a factor if we decide that those are in scope.  I think that they should be based on my earlier observation that a dynamic dictionary and general compression reduce to the same thing.  In this, the question that this should ask is to what extent an attack

Section 4.2.2 and 4.2.3 basically reduce to saying that compression is not encryption.  I don't think that there is much value in worrying about this.  I would instead say that the dictionary needs to be *no more secret* than the content it is used with as decompressors effectively allow for arbitrary querying of the dictionary and compressors do not attempt to protect dictionary content from someone with access to inputs or outputs.  In other words, take this question off the table.

I don't get Section 4.4.1.

A lot of the text in this section is addressed at the risks of having to dynamically fetch dictionaries.  There are a couple of simplifying assumptions that this touches on.  It might be better to start proscribing some of the more obviously bad options rather than to address them all in depth.  For instance, if a server points to a dictionary, to avoid history exfiltration I doubt that we could use a cached version of that dictionary even if another server pointed to the same resource.  At that point, as long as a server is accountable for the bytes it causes the client to retrieve, we're cool with a lot of these attacks.  Server can already point at large resources on other servers, and they frequently do.

# Biases

Section 3.3.1 reminds me that there is another "security" consideration inherent in this.  Depending on how dictionaries are managed, there are opportunities for bias in generation.  Take the case of a dictionary that is run over just the Facebook JS codebase.  That will produce an optimal result for Facebook content, but the extent to which it might also work for another large operator is probably diminished and a small site operator might be at a greater disadvantage.

# Nits

Section 4.1.2.1 mentions a draft that proposes padding for TLS.  Since Alfredo and friends published that draft, all new protocols have added padding: TLS, HTTP/2, and QUIC all include padding.  You might be better off referencing those.