Re: Compression dictionary draft ID - draft-meenan-httpbis-compression-dictionary-00

On Mon, Jul 3, 2023 at 10:14 PM Martin Thomson <mt@lowentropy.net> wrote:

> Hi Pat,
>
> On Sat, Jul 1, 2023, at 03:30, Patrick Meenan wrote:
> >  The spec is hopefully written in such a way that it is not specific to
> > the browser use case but does have some additional carve-outs for some
> > of the browser-specific privacy concerns.
>
> Given how delicate the security constraints are, this is probably
> insufficient:
>
> > In these cases, dictionary compression MUST only be used when both the
> dictionary and the compressed response are fully readable by the client.
>
> You previously said "clients, like web browsers", but I think that this is
> an error.  That's especially important given that this is your primary
> security mechanism.
>
> In a multi-tenant environment like the web, this needs to be very
> carefully - and fully - specified.  Could an image loaded by a page from a
> cross-site origin use this mechanism?
>

Sorry, there are 2 parts that are being protected:

1 - The readability of the contents of the dictionary and
dictionary-compressed resource.
2 - Side-channel tracking by origins abusing the dictionary as a cookie.

For #1, being cors-readable and forcing the payload to be readable anyway
for it to be used as either a dictionary or as a compressed resource would
mean that, yes, cross-origin images would be able to use the mechanism
since the payload would be readable by fetch() directly anyway.  A
non-readable cross-origin image would not be able to use this or be stored
as a dictionary and shouldn't be readable in that case.  I can see about
pulling in more spec language for exactly what constitutes cors-readable if
it would help.

For #2, I could see there being some situations where a cookie would not
normally be allowed but where the resource would be cors-readable
cross-origin.  We could introduce a requirement that both the dictionary
and payload must be credentialed requests as well (and pull in the spec for
what constitutes credentialed requests).  I'm not 100% sure that it's
different from abusing E-tag or Last-Modified with unique values that can
be server tracked which is why they're already partitioned by both the
cookie and cache partitioning but it would be best if we didn't introduce
another abuse vector.

Is there another risk that I'm missing?  I want the guard rails to be
complete but also keep it as succinct as possible to avoid complexity for
devs to understand where and how they can work.

What are some other multi-tenant non-browser clients that provide
caching/cookie-type storage but restrict the ability of their callers to
access the payloads (just trying to form a mental model since I'm mostly
familiar with browsers, intermediary proxies and native clients where the
proxies and native clients have full access and control).


> (I also see a bunch of formatting issues in the draft, but those are of
> less consequence.  Maybe I can recommend checking that the output matches
> expectations before publishing the next version.)
>
>
Sorry, just saw that the tooling going from markdown->ID lost some of the
breakpoints (and I need to figure out tables so I can better represent a
few of the sections).  The one thing that I don't know is what the best
practices are for sample HTTP headers that don't fit on a single line and
if it is ok to wrap them or if it is better to shorten the header value to
make it fit (might require an invalid string length for a hash but could be
clearer to read).

Thanks,

-Pat