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

Re: h2 padding

From: Greg Wilkins <gregw@intalio.com>
Date: Fri, 5 Sep 2014 08:48:49 +1000
Message-ID: <CAH_y2NH40KLoUZNoJQMXVzfo9zD5PxY9Fwpzz6df2CSLowVyOQ@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Brian Smith <brian@briansmith.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 4 September 2014 09:51, Roy T. Fielding <fielding@gbiv.com> wrote:

> We already have a paragraph somewhere that says padding should
> not be removed by an intermediary.  I have no problem with it also
> saying that secure intermediaries shouldn't reveal patterns within
> the content by writing them as distinct units when there is no need
> to do so, though I'd think such a thing would be defined by TLS itself.

I do have a problem with any text like this.  Writing scalable asynchronous
robust code is really difficult.  Adding in requirements that writing
must not reveal anything about the content is an escalation in complexity
that I do not think is justified or even achievable.  Next we'll be
constant time comparisons and other aspects.

It is just not reasonable to expect every HTTP2 implementation to be
hardened against these kind of issues.     They have enough difficult
to create scalable robust http infrastructure without needing to meta
every algorithm to ensure that it does not reveal sizes or frame boundaries
in some fashion.

I cannot see how we are going to test that applications actually implement
such requirements anyway.  Do you fail a test if a TCP frame boundary
to fall on a h2 boundary?  Or is it a statistical test?       Without wide
there is no certainty that such recommendations will be well implemented,
applications that care about this will have to implement their own solution
another layer.


Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.
Received on Thursday, 4 September 2014 22:49:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC