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

Re: Design Issue: Overlong Frames

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 10 May 2013 12:00:20 -0700
Message-ID: <CABkgnnX=bFRg39aK6Ba4XzcKEz84oyt7GL+US7zHw+wonQve6g@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 10 May 2013 11:29, James M Snell <jasnell@gmail.com> wrote:
> On Fri, May 10, 2013 at 10:36 AM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
>> On 9 May 2013 10:26, James M Snell <jasnell@gmail.com> wrote:
>>> Recommendation: Adding a short statement that a PROTOCOL_ERROR MUST be
>>> returned if a frame contains more bytes than what is expressly
>>> specified in the frame definition.
>>
>> That would prevent extension unnecessarily.  And it doesn't do
>> anything to improve security.
>
> How does it prevent extension? If someone wants to extend an existing
> frame to include new data, it can define a new frame type.

I can't extend GOAWAY.  Who knows, maybe I might want to be more
specific about the streams that will be processed prior to session
end.

>> When you want to harden security, you need to consider what equivalent
>> options are available to an attacker.  If I wanted to send you more
>> data, then I will use DATA frames.  Unless you can find a way to
>> curtail DATA I see no reason to clamp down here.
>
> In my experience, it's generally better to limit the exploitation options ;-)

It doesn't limit options in any meaningful way.  This would be
analogous to double-deadlocking the front door while leaving the
adjacent windows wide open.  I know that the extension argument isn't
especially strong, for a range of reasons, but I see no point in
over-engineering this aspect.
Received on Friday, 10 May 2013 19:30:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC