- From: 陈智昌 <willchan@chromium.org>
- Date: Fri, 10 May 2013 16:56:20 -0300
- To: James M Snell <jasnell@gmail.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAA4WUYi0dsLZ9vdTHmaZsteK=fcGTYdwO+tn6L7SM0qYQTX0Dg@mail.gmail.com>
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. >
Received on Friday, 10 May 2013 19:56:53 UTC