W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: h2 padding

From: Guille -bisho- <bishillo@gmail.com>
Date: Thu, 4 Sep 2014 00:30:40 -0700
Message-ID: <CAMSE37sMUN5wGdUCVjZTtouH5u+i9EJOYg936G8w-049LsswNw@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC