W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Frame Length Restrictions

From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 21 Apr 2014 19:06:24 -0700
Message-ID: <CAP+FsNc0s81tBta=c-ZUWh_VCpx-ODi=SdoMrrPR_0qKuySiww@mail.gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Johnny Graettinger <jgraettinger@chromium.org>, Patrick McManus <mcmanus@ducksong.com>, K.Morgan@iaea.org, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
I don't have a working attack in hand, but essentially it leaks info:
With an 8 byte minimum, it becomes easier to defeat the purpose of
padding-- one constructs a test which looks for an 8-byte jump in output
size to determine the actual output size.
-=R


On Mon, Apr 21, 2014 at 5:30 PM, Jeff Pinner <jpinner@twitter.com> wrote:

>
>> Presumably you could take those 16K frames and split them into 16K-9
>> frames before adding padding.  You could even ask the upstream servers
>> not to produce 16K frames.  You could even ask the upstream servers to
>> pad properly.
>>
>
> I could only split frames if I always split frames, otherwise I would leak
> the original message size. If I always split frames than this is equivalent
> to having an 8-byte minimum on padding. In this case we should just use a
> specific padding frame instead of adding padding fields to every data frame
> based on flags. Especially since that removes the need to check if the
> padding length exceeds the frame length.
>
> So let me ask that question then: Why is an 8-byte minimum on padding
> unacceptable?
>
Received on Tuesday, 22 April 2014 02:06:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC