Re: Frame Length Restrictions

On Mon, Apr 21, 2014 at 3:22 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 21 April 2014 14:56, Jeff Pinner <jpinner@twitter.com> wrote:
> > Alternatively, and equally acceptable to me, would be to leave the 14-bit
> > length field and further restrict the HTTP layer to only use 2^14 - 9
> bytes
> > (to allow for 8 bytes of padding).
>
> I think perhaps you need to speak a little more about why reframing
> doesn't work for you.
>

The goals here are:

1) achieve a desired (to-be-provided) frame length distribution
2) achieve this with the minimum amount of padding
3) achieve the desired distribution regardless of the input data stream

The intend is not to avoid reframing, it's to avoid a discontinuity in the
output distribution.

With the current draft, I have to pad assuming that at some point I will
receive a frame with the maximum application data size. This frame cannot
be padded arbitrarily, it must have a minimum 8 bytes of padding since any
padding requires splitting and so I must add a frame header.

Now, if I operate under the assumption that an adversary can force my
server to produce full size frames, then at any point the adversary can
force my implementation to add at least 8 bytes of padding, revealing
information about the targeted distribution. To prevent this, any padding
distribution must pad by at least 8 bytes.

Now, if this is acceptable, then it must be acceptable to always pad by at
least 8 bytes. In which case the current padding implementation is overly
complicated and we should just be padding via a PADDING frame (or perhaps
two, one subject to flow control and one not).

If this is not acceptable, then either the frame size has to increase or
the allowable application size decrease.