Re: h2 padding

On 30 August 2014 12:14, Roy T. Fielding <fielding@gbiv.com> wrote:
>
> I think that is a mistake.  Forcing padding to zero makes it less random
> and causes it to be compressed to nothing if a higher layer compresses
> the stream.  A requirement on senders cannot prevent bad actors from
> sending non-zeros (assuming this is to prevent smuggling of data).

This was entirely intentional.  And this is less about bad actors than
it is about reducing the likelihood that a bad implementation escapes
detection.  I personally consider the idea that we might prevent
somehow smuggling in HTTP to be laughable.

Note that these zero bytes cannot be compressed.  We're requiring no
compression in TLS, consistent with its eventual removal in 1.3.

[...]

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

The basic property that we're looking for is that the set of frames
that comprise for a given communication pattern are indistinguishable
from the frames for a different communication pattern.  When Thai says
"padding should have 1-byte increments", it might look like we took
the most aggressive interpretation of that.  We interpreted that
padding needed to be in the range [0,n), when [d,n+d) is good enough
to meet that requirement alone.

If an implementation wanted to pad frames between 120 bytes and 143
bytes out to be indistinguishable, the current scheme permits no
additional overhead for the 143 byte sequence, and allows a minimal 23
byte pad for the smallest.  However, with a new frame type, the
overhead of a frame boundary would reveal a 142 byte sequence, and any
scheme would have to allow for the sudden appearance of a frame
boundary.  That means that you need to include a padding frame for all
of the frames.

That alone wouldn't be sufficient cause to build a scheme like what we
have, which is definitely ugly.  Being strictly parsimonious with
bytes while you pad is oxymoronic.

The main reason for the ugly is that we're attempting to avoid other
side channels at the same time.  There are more avenues for leakage
than simply length.  The ugly scheme ensures that padding of payloads
is flow controlled, ensuring that padding is covered by flow control.
This avoids having WINDOW_UPDATE timing inadvertently revealing
length.

We did discuss moving the padding to the start of the frame so that
you don't leak timing, but it's not clear that we can prevent
finer-grained timing based attacks anyway, so we decided not to.

Received on Tuesday, 2 September 2014 21:51:56 UTC