Re: h2 padding

On 5 September 2014 09:10, Martin Thomson <> wrote:

> Rather than contemplate the infinite and byzantine complexity that
> might arise, perhaps it would help to demonstrate how a feature like
> this could provide security.  As has been discussed, Twitter pad
> profile images so that it is hard for a passive observer to use
> traffic analysis to determine which profile has been accessed by a
> given user.

I'm not disputing that padding can be used to improve security.

Your example is indeed a good example of security padding.   But I
just don't see how that example could be translated to an example that
automatically applies padding at the framing layer.

The framing code that segments the profile image into h2 frames
will not that that it is a profile image, it probably wont even know it is
image or that it is sending it over TLS.    More over, the padding in this
case does not need to be frame by frame and adding padding to the
end of the stream would be sufficient.    Also, as this example clearly
shows, applications that care can already pad without help from the
framing layer and in this case any padding automatically applied by h2 will
just be wasted bandwidth.

Are there any examples of security padding that can be applied by the
framing layer?     When is it that a framing layer can make up for lack of
caring about security by an application?

I do not dispute that padding can be a good security measure, nor that
there are some use-cases that care about side channel leakage from
frame boundaries, processor timing, power consumption, CPU cycles

What I am disputing is that providing padding within the h2
framing layer can help those use-cases in any meaningful way?

If we are considering adding restriction on how padding can be rendered
into TCP frames, then my dislike of padding is escalated to can't live with


Greg Wilkins <> HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.

Received on Friday, 5 September 2014 00:23:06 UTC