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

Re: fixing TLS vulnerabilities with h2 was: ezflate: proposal to reinstitute deflate header compression

From: Greg Wilkins <gregw@intalio.com>
Date: Thu, 5 Jun 2014 13:09:59 +0200
Message-ID: <CAH_y2NHZDki46xhikjk7mW+kgzZW71P-xALMpLohO1GsmAMFFA@mail.gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>
Cc: "K.Morgan@iaea.org" <K.Morgan@iaea.org>, Willy Tarreau <w@1wt.eu>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "C.Brunhuber@iaea.org" <C.Brunhuber@iaea.org>
On 5 June 2014 13:02, Greg Wilkins <gregw@intalio.com> wrote:

> Regarding padding: I don't quite understand the argument against allowing
> it in the spec. If the h2 library's API makes frame padding options
> available to the application, then the application, which has more chance
> of knowing things like the provenance and value of the bytes, can choose to
> obfuscate them. If the application doesn't use padding, or does so
> improperly, does that count as a security failing of HTTP/2? Is it better
> to make everyone never pad at this level?


Having the padding in the spec is not that much of an intrusion, but I just
don't see what good it does.   If an application wants to pad it's data for
security reason, then it does not need a transport mechanism for that.
The only reason the transport needs to be aware of padding is if the
transport is expected to do something with it - ie like generate it.   But
as the warnings in the draft clearly make out, generating padding is
apparently non trivial and should only be done by experts with detailed
knowledge of the actual payload.

So if the transport is not going to generate the padding, not handle the
padding, etc. then why does the transport even need to know about the
padding?

To me it is setting false expectation that the implementation of h2 will be
safe from leaking information about their meta data and payloads.

cheers






-- 
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, 5 June 2014 11:10:28 UTC

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