Re: Design Issue: Overlong Frames

[James M Snell <[e-mail]>]

On May 10, 2013 12:00 PM, "Martin Thomson" <[e-mail]> wrote:
>
> 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.
>

If there are non-theoretical reasons for why one may wish to extend a frame
like goaway, then extensibility should be expressly included in the design
as part of the format.

- James

> >> 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.