Re: h2#373 HPACK attack mitigation options

The issue isn't the reference set in this case, rather it is that the
originator of the request != the destination for the request, which allows
the originator to probe the compressor dynamic state-table.
If options 1 or 4 are taken, then grouping or some similar signaling may
need to be reintroduced. Opening an outgoing connection for each incoming
connection is not the greatest thing in the world as it defeats several of
the nice properties of HTTP/2.

Option #2 doesn't require this.

HPACK/HTTP2 is not currently well optimized for intermediaries. This was a
conscious decision to reduce protocol complexity at the tradeoff of some
optimality.
-=R



On Wed, Mar 5, 2014 at 3:47 AM, Roland Zink <roland@zinks.de> wrote:

> What does this mean for proxies? Should proxies open a new outgoing
> connection for each incoming?
>
> HPACK can do a diff to the previous request. If the previous request is
> from a different client then the diff might be rather large. Should HPACK
> be extended to allow several reference sets and switch between them?
>
> Roland
>
>
> On 05.03.2014 11:23, Martin Thomson wrote:
>
>> An implementation is potentially affected by this attack if it allows
>> multiple actors to influence the creation of HTTP header fields on the
>> same connection.  It also requires that header fields provided by any
>> one actor be kept secret from any other actor.  In the canonical
>> example of a browser, the invariant we want to maintain is that any
>> origin (the primary class of actor in that context) is unable to
>> access header fields that are created by other origins, or the browser
>> itself.
>>
>> I'll note that this is also potentially an issue for non-browsers that
>> use proxies.
>>
>>
>>
>
>