Re: h2 padding

On 31 August 2014 05:14, Roy T. Fielding <fielding@gbiv.com> wrote:

> I think there is a misunderstanding here.  Padding is used to allow an
> opaque stream to not reveal its size.  Frames are not opaque.  There is no
> need for padding within a frame.  The security need is for padding to be
> allowed after a frame when both are enveloped within an opaque stream.
>
> Naturally, this is best accomplished with a padding frame type.
>


I agree that having padding within the frame itself is not called for (and
pretty much unusable), but I would go further and ask why does the framing
layer need to know about security padding at all?

Telling the framing layer is inviting it to handle it differently and the
moment there is any different handling, then there are increased chances
that you will leak the information you are trying to hide (eg by timing or
other handling artefacts).   The spec makes it very clear that the
application of security padding is something that should be done with care
and knowledge of the application data:

   - *“Redundant padding could even be counterproductive.”*
   - *“Correct application can depend on having specific knowledge of the
   data that is being padded.”*
   - *“To mitigate attacks that rely on compression, disabling or limiting
   compression might be preferable to padding as a countermeasure.”*
   - *“Use of padding can result in less protection than might seem
   immediately obvious.”*
   - *“At best, padding only makes it more difficult for an attacker to
   infer length information by increasing the number of frames an attacker has
   to observe.”*
   - *“Incorrectly implemented padding schemes can be easily defeated.”*

Thus security padding cannot be applied at the framing layer and typically
there are no channels for applications to tunnel security knowledge about
payloads down to the framing layer. If security padding is desired by
knowledgeable application layers, then there are already places for padding
to be added without informing the framing layer that it is padding:  extra
headers, trailers, within the content-type itself, pong frames, etc.

Unless there are clear directives of how the framing layer should generate
security padding, then I don't think there should be any explicit handling
of padding by the framing layer.

On the other hand,  if h2 had padding for frame header alignment reasons,
then I see no problems in some smart implementations using that also for
security padding.

However, if padding is to be used for frame header alignment, then a
padding frame with normal frame header does not work because it can't do
minimal octet alignment.    Instead we could use padding octets that are
indicated by having the high bit set and the remaining bits used to
indicate how many padding octets follow:

   0
   0 1 2 3 4 5 6 7
  +-+-+-+-+-+-+-+-+
  |1| Pad count   |
  +-+-------------+

I guess conceptually this is a padding frame with a special 1 byte header.
This allows arbitrarily small padding and the mechanism can be used for
both alignment and security padding.

regards


-- 
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.