Re: WebSockets and masking

Hi Dragana, and thanks for writing this up!

I agree with you that the main motivations for masking don't matter as much
when WebSocket runs over TLS or QUIC (though AEADs without random IVs allow
a collaborating client and server to predict the next keymat...). However,
it's not clear to me why the overhead of masking matters. I wouldn't expect
the XOR to be visible on CPU traces. Is this masking causing noticeable
performance issues in your environment?

Thanks,
David

On Fri, May 19, 2023 at 2:11 PM Dragana Damjanovic <
dragana.damjano@gmail.com> wrote:

> Hi,
>
> I wrote a draft that proposes adding an extension to WebSockets to
> negotiate "no-masking". The extension should be used only if intermediaries
> cannot see unencrypted traffic. In this case, the masking is not needed,
> and omitting it would reduce needed processing. The proposal has some
> problems, but I would like to hear the opinion of the group and if people
> are interested in such a feature.
>
>
> https://www.ietf.org/archive/id/draft-damjanovic-websockets-nomasking-00.html
>
>
> A problem that I have identified with the proposal is that it will require
> TLS terminating middleboxes to change (they will need to remove the
> extension from the list), otherwise, servers behind them could wrongly
> negotiate the extension. This is not optimal.
>
> Other approaches I have considered:
>
> - making it HTTP/2- and HTTP/3-only feature and negotiating it via
> settings (In this way it cannot be transfer to unencripted part of a path).
> This is not ideal.
>
> - Creating a new header for the feature and adding it to the “Connection”
> header in the case of HTTP/1.1 and transferring it as a setting in the case
> of HTTP/2 and HTTP/3, and
>
> - creating a new version of the WebSocket protocol, but the negotiation of
> a new version is not ideal for this purpose and may have the same problems
> as my proposal in the draft.
>
>
> Other ideas are welcome.
>
> I would like to hear your opinion.
>
> Best,
>
> Dragana
>