Re: Design Issue: Overlong Frames

[William Chan (陈智昌) <[e-mail]>]

Non-theoretical reason for extending GOAWAY: adding debug strings
explaining an error in more detail.

No comment on extensibility mechanisms.


On Fri, May 10, 2013 at 4:40 PM, James M Snell <[e-mail]> wrote:

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