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

Re: h2 padding

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 3 Sep 2014 16:51:34 -0700
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <726AD6AA-A6A9-470F-A0DA-428278E6458C@gbiv.com>
To: Brian Smith <brian@briansmith.org>
On Sep 3, 2014, at 3:31 PM, Brian Smith wrote:
> On Wed, Sep 3, 2014 at 1:12 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>> On Sep 2, 2014, at 11:07 PM, Brian Smith wrote:
>>> Consider an implementation that sends every frame in its own TCP
>>> packet, perhaps with a 1 minute delay between frames. Such an
>>> implementation would conform to Roy's suggestion, but it would
>>> partially or completely defeat the purpose of the padding.
>> 
>> Perhaps it will help if we clarify the assumptions here.  The first is
>> that the application is adding padding for a reason and not simply because
>> it is cool.  The second is that the rate at which they send data is under
>> their control, along with how that data is arranged in h2 padded form.
> 
> In order for padding to be a useful security feature, it must provide
> end-to-end protection. That is, when the origin server sends
> data||padding, that data||padding needs to be preserved and processed
> as a single unit through all hops (i.e. by any/all proxies). But,
> draft 14 doesn't say that. Therefore, the assumption that "how that
> data is arranged in h2 padded form" is under the applications' control
> is violated with in draft 14.

We are talking about padding added within a secure e2e connection
(from the PoV of the client -- it might actually be a connection to
a gateway like Roberto described).  The upper layers (hopefully) have
no idea where the frames are because they are encapsulated by TLS
or some other encryption.

If we also have secure personal proxies in the mix that are doing
something weird with the data after decoding the encrypted traffic
and then reframing it and re-encrypting it to transport as an
intermediary to some distant user agent and NOT taking care to
transmit the data in a way that is independent of the raw content
of that data, then all bets are off.  I have no interest, whatsoever,
in designing to that scenario.

We already have a paragraph somewhere that says padding should
not be removed by an intermediary.  I have no problem with it also
saying that secure intermediaries shouldn't reveal patterns within
the content by writing them as distinct units when there is no need
to do so, though I'd think such a thing would be defined by TLS itself.

....Roy
Received on Wednesday, 3 September 2014 23:51:56 UTC

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