Re: h2 padding

On Sep 2, 2014, at 1:45 PM, Patrick McManus wrote:

> 
> On Sat, Aug 30, 2014 at 3:14 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> here 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.
> 
> Hi Roy - 
> 
> Nobody has mentioned this yet in this thread so I will. The existing design, which I think is universally regarded as awkward, meets the requirement for 1 byte minimum pads which is rooted in Thai Duong's comment here: https://github.com/http2/http2-spec/issues/344  .. a new frame would either need a non standard frame header as Greg mentions (also awkward in a different way!) or be too big.

Hi Patrick,

Thanks for the useful information and pointer.  Unfortunately, it seems
the WG misunderstood the fairly generic advice that was given by the
Google team.  In particular, where they said "The padding should have
1-byte increments" what they meant is that padding should be able to
expand or reduce by a single byte so that it can mask single byte
changes to the content (and not look statistically odd).

The right way to do this (if it is done at all in the application layer)
is to always send the padding frame, for responses from a given resource
that needs padding for some reason, and only vary the amount of padding
sent each time (even if it is zero).  Deciding whether or not to write
the padding frame/length, at run time, would be revealing on its own.
Hence, the minimum padding under my proposal would be 64bits (the price
of a padding frame type) but the padding itself is in 1-byte increments
when compared to other traffic within the needs-to-be-padded space.

That said, I should clarify that I agree with their other advice as well.
Padding for cryptographic reasons should be handled at other layers.
However, sometimes it isn't, and in those cases it can only be handled
where one has control. The extremely rare cases in which we would want
to do padding in h2 (as opposed to within TLS or within the content)
are adequately covered by a padding frame, which adds no complexity to
the rest of the protocol.  In contrast, having optional fields at the
beginning of every Headers, Data, and Push_Promise frame is adding
complexity on every single interaction via h2, even if those fields
are never used in practice.  I think that's a bad trade-off.

....Roy