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

Re: h2#373 HPACK attack mitigation options

From: Michael Sweet <msweet@apple.com>
Date: Wed, 05 Mar 2014 08:18:31 -0500
Cc: Roland Zink <roland@zinks.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <A3525724-9DFD-4312-88D2-3CCD3379C943@apple.com>
To: Roberto Peon <grmocg@gmail.com>

On Mar 5, 2014, at 8:14 AM, Roberto Peon <grmocg@gmail.com> wrote:
> I have use-cases where I'd like to mux many connections onto one, e.g. when I may not have enough ephemereal port space to serve that number of connections.
> The advantage is not theoretical there :)


I think I've voiced my opposition to the current HPACK enough times...  Between stream management, HPACK, and priority management, proxies are going to have a lot more work to do when muxing...

> -=R
> On Wed, Mar 5, 2014 at 5:12 AM, Michael Sweet <msweet@apple.com> wrote:
> Roberto,
> On Mar 5, 2014, at 7:22 AM, Roberto Peon <grmocg@gmail.com> wrote:
>> 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.
> FWIW, it wouldn't be the end of the world as you are still reducing the connection load from N connections per client to 1 per client - probably an order of magnitude difference with today's browsers.
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Wednesday, 5 March 2014 13:19:00 UTC

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