- From: Guille -bisho- <bishillo@gmail.com>
- Date: Thu, 4 Sep 2014 00:30:40 -0700
- To: Willy Tarreau <w@1wt.eu>
- Cc: Jason Greene <jason.greene@redhat.com>, Brian Smith <brian@briansmith.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, Roy Fielding <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
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 implementations. 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 -ℬḭṩḩø- <bishillo@gmail.com> :wq
Received on Thursday, 4 September 2014 07:31:27 UTC