- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 3 Sep 2014 16:51:34 -0700
- To: Brian Smith <brian@briansmith.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.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