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