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

Re: h2 padding

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 3 Sep 2014 15:30:55 -0700
Message-ID: <CAP+FsNdmtN9EebAiTfh4DaGDvgaCD8NR5Y8GYznpZWfhSG9nYg@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: Brian Smith <brian@briansmith.org>, Jason Greene <jason.greene@redhat.com>, 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>
Truthfully, many folks who write applications will not think about this
kind of thing, and providing something which does handle this for them
automatically is likely quite a bit better than nothing.

Sometimes (reverse) proxies are called into the picture to help out with
some of these issues.
In such cases, having a mechanism that allows a proxy to manipulate the
data on the wire (likely with simple settings/rules for that
application/product/endpoint) with a guarantee that it is not affecting an
accidental semantic change is useful.


On Wed, Sep 3, 2014 at 3:22 PM, Greg Wilkins <gregw@intalio.com> wrote:

> On 4 September 2014 05:33, Brian Smith <brian@briansmith.org> wrote:
>> That isn't the issue. The issue is with an implementation, such as a
>> proxy, that does something like "split the padding into its own frame
>> and put the data in another frame," and/or putting those split frames
>> in separate TLS records and/or TCP packets, which is currently allowed
>> (AFAICT) in draft 14.
> Which is precisely why telling the framing layer about security padding is
> a self defeating exercise.   TCP packet boundaries are just one potential
> artefact that an observer can use to guess payload sizes, handling time is
> another and I'm sure somebody could even observe CPU and/or power drain if
> they really wanted to get spooky about it.
> If we want security padding to be truly indistinguishable from real
> payload, then don't tell the framing layer that it is padding.
> Better to have no security than false security.
> --
> Greg Wilkins <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com  advice and support for jetty and cometd.
Received on Wednesday, 3 September 2014 22:31:23 UTC

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