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

[Rob Sayre <[e-mail]>]

On Thu, Dec 5, 2019 at 2:45 AM Martin Thomson <[e-mail]> wrote:

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

[...]


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

This paper includes a good overview of the general message-size problem,
including timing attacks:

https://hal.inria.fr/hal-00732449/document

Compression is mentioned at the end of the introduction.

The cost of padding is influenced by at least two factors:

1) The size distribution of the non-padded content. In particular, padding
isn't very costly if the content always fits in a small number of packets.
2) Whether a reliable end marker is present in the content or the
application framing, so that the client can at least ignore padding bytes.

The authors recommend what they call an "anonymity policy" for a given set
of content, because a policy tuned for a specific set of content will
outperform a general policy.

thanks,
Rob