W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Transfer-codings, mandatory content-coding support and intermediaries

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Mon, 21 Apr 2014 23:13:14 +1000
Message-ID: <CACweHNAR8RvW1X1XJSPwh_VPQh3diz8ijsoaL6NXexWGr_hYUg@mail.gmail.com>
To: K.Morgan@iaea.org
Cc: Martin Thomson <martin.thomson@gmail.com>, Patrick McManus <pmcmanus@mozilla.com>, Mark Nottingham <mnot@mnot.net>, C.Brunhuber@iaea.org, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 21 April 2014 22:22, <K.Morgan@iaea.org> wrote:

> Regarding my suggestion below, will somebody please at least respond and
> tell me why I'm wrong and/or give another suggestion?
> On 19 April 2014 21:54, MORGAN, Keith Shearl wrote:
> > I suggest something like the following...
> >
> > Intermediaries MUST NOT add GZIP compression to a DATA frame.
> Intermediaries MAY
> > remove GZIP compression frome DATA frames if necessary. Intermediaries
> MAY also
> > remove and re-apply GZIP compression, so long as all compressed data were
> > originally compressed by the origin.
> >
> > For example, an intermediary might elect to remove GZIP compression for
> local
> > storage in its cache in order to more easily extract a range from the
> content. In
> > this case, when serving a range, the intermediary can choose to send the
> range in
> > DATA frames with no compression or with GZIP compression (or a
> combination
> > thereof).
It's too hard to enforce that MUST NOT; it's quite likely to become an RFC
6916-style "MUST NOT (BUT WE KNOW YOU WILL)"‚Äč. Or put more politely: if
someone implemented it by mistake, how would anyone ever detect it?

An alternative which I'm starting to imagine might be to use END_SEGMENT to
delineate secret data and potentially-attacker-supplied data; that way we
can ensure that the two sets of data never end up in the same DATA frame /
compression context. That resolves the vulnerability I'm aware of
introduced by compression; I don't know how to protect against
vulnerabilities of which I'm not aware, in anything.

  Matthew Kerwin
Received on Monday, 21 April 2014 13:13:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC