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: Matthew Kerwin <matthew@kerwin.net.au>
Date: Thu, 5 Jun 2014 14:36:46 +1000
Message-ID: <CACweHNCwrO9hmncfFOfaMSVvY5P+h1=js4WHRAq30uAKpiRj7g@mail.gmail.com>
To: K.Morgan@iaea.org
Cc: Greg Wilkins <gregw@intalio.com>, Willy Tarreau <w@1wt.eu>, Herve.Ruellan@crf.canon.fr, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, C.Brunhuber@iaea.org
On 5 June 2014 13:37, <K.Morgan@iaea.org> wrote:

> Hi Greg-
>
> Thanks for the feedback. Changing the subject though to more adequately
> reflect what you discussed, which IMO is an important point, namely:
>
> Is it the responsibility of h2 to fix security vulnerabilities in TLS?
>
> You make a good argument that the answer is no. The very purpose of
> protocol layering is separation of concerns. In other words, the security
> protocol, in this case TLS, should be secure (or patched if it isn't) - the
> underlying protocol shouldn't have to worry about it.
>
> Nobody should ever be concerned about whether their bank is using the
> "right" h2 implementation - eg one that uses constant time string
> comparison functions.
>
>
‚ÄčI really feel like these CT string functions are a bit of a strawman.
People are allowed to put whatever magic sauce and marketing buzzwords they
like in their implementations; if that helps drive adoption or gain market
share, ‚Äčthen so be it.

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?
Received on Thursday, 5 June 2014 04:37:15 UTC

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