Re: h2 padding

I still don't see the benefits of supporting padding at the framing
layer. The padding can be equally controlled from application by
adding a random-length, random-content http header, with similar
effectiveness, and with the side benefit that it's backwards
compatible. If a browser starts detecting a ton of requests against
similar url can enable and add this header with little impact to
compatibility. And we will get rid of a lot of complexity in the
HTTP/2 spec.

Non browsers are much less susceptible to BREACH/CRIME attacks, can't
be controlled that easily, so having padding at framing doesn't
translate into a critical benefit in security for client http2 library

On top of that:
- padding doesn't make sense for plain-text http2, is a waste having
it taking space on all frame headers. TLS should protect against
BREACH/CRIME on its own.
- when using VPNs (as suggested use-case), better have that vpn handle
this properly at that layer, or any usage of HTTP/1 will make them
still vulnerable.
- for protecting against client traffic matching when using
intermediate parties, timing will be probably so easy to exploit that
the use-case is minimal IMHO.

And finally, as discussed, the padding at http/2 framing level is hard
to do it right with the non-obvious relation between frame lengths and
actual network packets, the interaction with intermediate parties and
so on.

Guille -ℬḭṩḩø- <>

Received on Thursday, 4 September 2014 07:31:27 UTC