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 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. - 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, 15 November 2017 23:34:30 UTC