Re: #445: Transfer-codings

On Wed, Apr 9, 2014 at 11:16 PM, Matthew Kerwin <matthew@kerwin.net.au>wrote:

> I've started keeping track of my T-E proposal in github[1], and have been
> attempting to come up with ways to address people's concerns.
>
> * The easy issue was the size of identifiers, which I've reduced to 8 bits
> in my current text -- i.e. 256 possible values. The worst case commitment
> as a result is 256 rank values, which I've also reduced to 8 bits -- so 256
> bytes. However as I and others have pointed out, the minimum commitment as
> a result of this proposal is nil, and a reasonable realistic value is
> probably 1-2 bytes per connection.
>

Actually, the size committment for any receiver of something which uses T-E
would be the minimum size of the encoding context. For gzip, this is
decided by the sender and is not trivial, and thus provides for an
interesting DoS vector against the receiver.
This would completely throw out the things we've done in HTTP/2 to ensure
that the receiver controls the size of the amount of memory it needs to
use. That seems silly at best.


> * I wanted to keep the rank because I'd like the ability for someone to
> change their mind about an encoding. I would be happy with a single bit, if
> I could come up with a way to pack it into the settings frame that doesn't
> make me feel yucky. The case I'm addressing is a proxy that, having
> advertised support for gzip, finds itself being zip-bombed (or possibly
> just under an unexpectedly high load) and decides to stop receiving gzip
> payloads from downstream.
>
> * I've not included any suggestion of how people could or should use rank
> values to determine a preferred encoding. I don't think that's a problem
> though; RFC 2703 and RFC 2295/2296 exist if people really need inspiration.
> It could also go away if rank is reduced to a single bit.
>
> * An issue I'd like to address is the ability to specify multiple
> encodings on a single frame. This could be done by either expanding the
> proposed Encoding field in the DATA frame to some fixed multiple (e.g. 4
> encodings), or with a length-prefixed or a null-terminated (er,
> identity-terminated) list.
>
> * The big issue I'm still trying to get straight in my head is the
> objection that compression can reduce security when applied by part of the
> transport chain that doesn't have full knowledge of the properties of the
> data. The server has no way of signalling that intermediaries shouldn't
> apply compression.
>
>    My thoughts on this are that end-to-end encryption is meant to solve
> that problem, by making it very hard for intermediaries to modify your
> data. Also: the known compression-based vulnerabilities are based on
> sharing a single compression context between secret and public data; since
> this proposal uses a unique context per compressed frame, and since it's
> probably not likely that intermediaries would bother coalescing data
> frames, all the server has to do is send the secret and public bits in
> separate frames. Not a bullet-proof solution, but not unreasonable.
>
>
There are a large number of places where MITM proxies are deployed,
unfortunately, and I expect this would likely increase after HTTP/2 is
widely deployed.
That means that we cannot count on end-to-end encryption for delivering
security properties.
As an example, that is why the HPACK compressor has the ability to
indicated that no intermediary should ever compress data with X.

It is simply not safe for intermediaries to do this kind of compression
unless they have some prior (and up to date) knowledge about the provenance
of the data comprising the stream.
This is unlikely at best.
-=R




> Does anyone else have a concern that I've not addressed? Or possibly one
> that got lost in the volume of the discussion?
>
>
> [1]:
> https://github.com/phluid61/http2-spec/compare/445-transfer-codings#files_bucket
>
>
> --
>   Matthew Kerwin
>   http://matthew.kerwin.net.au/
>