On 5 June 2014 06:36, Matthew Kerwin <matthew@kerwin.net.au> wrote: > 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? > -- 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:02:47 UTC