Re: New Version Notification for draft-mcmanus-httpbis-h2-websockets-02.txt

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