Re: Design Issue: Overlong Frames

If that's a real possibility, then we can easily add an optional length
prefixed text field to the goaway frame definition.
On May 10, 2013 12:56 PM, "William Chan (陈智昌)" <willchan@chromium.org>
wrote:

> 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 <jasnell@gmail.com> wrote:
>
>>
>> On May 10, 2013 12:00 PM, "Martin Thomson" <martin.thomson@gmail.com>
>> wrote:
>> >
>> > 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.
>> >
>>
>> 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.
>>
>
>