Re: Design Issue: Overlong Frames

[Martin Thomson <[e-mail]>]

On 10 May 2013 11:29, James M Snell <[e-mail]> wrote:
> On Fri, May 10, 2013 at 10:36 AM, Martin Thomson
> <[e-mail]> wrote:
>> On 9 May 2013 10:26, James M Snell <[e-mail]> 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.