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

Re: Padding for PUSH_PROMISE frames

From: Roberto Peon <grmocg@gmail.com>
Date: Fri, 14 Feb 2014 14:06:17 -0800
Message-ID: <CAP+FsNfqJ88sQW3KrDW4hu-iCcPH=ZkGGrZtLnEc7NWT6Hv1_g@mail.gmail.com>
To: Nicholas Hurley <hurley@todesschaf.org>
Cc: IETF HTTP WG <ietf-http-wg@w3.org>, Jeff Pinner <jpinner@twitter.com>
Yup. Padding should be on any frame including a headers block, plus the
data frame.

On Fri, Feb 14, 2014 at 2:01 PM, Nicholas Hurley <hurley@todesschaf.org>wrote:

> I thought about adding padding to everything, but like Roberto said, it
> gets even trickier to do correctly (i.e., without messing up the security
> properties), and it seems a little silly to me to add padding to a frame
> that has a constant size. Adding it to PUSH_PROMISE, though, allows hiding
> the true size of the promised headers, and makea processing of both that
> and HEADERS frames almost the same, conceivably simplifying  implementation.
> I can see an argument for it but... meh. Padding is not a security feature
> unless it is used right. Adding it everywhere doesn't really help that, and
> opens up stuff even wider for abuse in the myriad cases where it has no
> real security benefit.
> -=R
> On Thu, Feb 13, 2014 at 9:39 PM, Jeff Pinner <jpinner@twitter.com> wrote:
>> Should we consider adding padding to all frames?
>> We have two bits reserved at the beginning of the length field that we
>> could use for the two padding flags, independent of frame type.
>> On Thu, Feb 13, 2014 at 9:26 PM, Nicholas Hurley <hurley@todesschaf.org>wrote:
>>> All,
>>> Right now (as of draft-10), DATA, HEADERS, and CONTINUATION frames can
>>> contain padding to obscure the actual size of the data being sent. I
>>> believe it would make sense to also add the option for padding to
>>> PUSH_PROMISE frames, as they carry (pretty much) the same type of payload
>>> as HEADERS frames, and can benefit from padding in the same way.
>>> I can make a pull request if others think this is a good idea.
>>> Thoughts?
>>> -Nick
Received on Friday, 14 February 2014 22:06:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC