- From: Takeshi Yoshino <tyoshino@google.com>
- Date: Wed, 22 Nov 2017 18:36:09 +0900
- To: Patrick McManus <mcmanus@ducksong.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAH9hSJYf3NLvo2NBqmvOB0ArtdAN5soE19UTU7X7tBkbL2mVtQ@mail.gmail.com>
On Thu, Nov 16, 2017 at 8:34 AM, Patrick McManus <mcmanus@ducksong.com> wrote: > > > On Wed, Nov 15, 2017 at 6:14 PM, Takeshi Yoshino <tyoshino@google.com> > wrote: > >> "due to its multiplexing nature" in the introduction section looks >> redundant. >> >> > thanks! > > >> Given that we drop the Sec-WebSocket-Key/Sec-WebSocket-Accept header >> considering that SETTINGS+:protocol is sufficient to ensure everyone on the >> path understands WebSockets (tunneling), I suggest that we also drop the >> client-server frame masking while also allowing masking as optional for LBs >> that don't want to parse/rebuild frames but forward everything after >> upgrading. >> >> > I don't think we can go there for a couple of reasons > > a] that kind of change to the guts of 6455 is not in scope for httpbis - > to do this work here we need to limit ourselves to how http/2 initiates > websockets > > OK. I'm fine with making sure that we decouple the effort into building a general tunneling solution and some amendment to RFC 6455. The latter could be discussed later. > b] part of the threat model for the masking is an otherwise passive > intermediary seeing a cleartext HTTP fragment (created by ws content) and > acting on it. as neither hybi nor httpbis made their protocols prohibit > cleartext (ugh) that threat isn't really changed by this document. > Ah, yes. Agreed with your suggestion below. > > - but I do think you could very easily do a websocket extension that > turned off masking for wss:// contexts. That would be separate from this > work.. I would expect it to be pretty easy.. maybe dispatch is the right > ietf venue at this point. I think it would be easy to find implementer > interest. >
Received on Wednesday, 22 November 2017 09:36:56 UTC