[Cryptography] RFC proposal draft text

Ismail Kizir ikizir at gmail.com
Mon Nov 21 08:56:40 EST 2016


Hello,

Below, I wrote proposal draft text about the subject I've previously mentioned.
My English is poor.
And I don't know much about RFC submission style.
I will appreciate any comments, critics, new ideas and help.
I will continously update this text in my blog until I submit it to
IETF at: http://ismail-kizir.blogspot.com.tr/2016/11/websocket-extension-noxormask-rfc.html

Thanks in advance
Ismail Kizir

---------------------------------------------------------------------

Websocket-Extension: NoXORMask RFC Draft

Websocket is a robust, general, widely accepted and adopted
communication protocol described in RFC 6455
(https://tools.ietf.org/html/rfc6455)

The communication starts as a standard http or https request and then
upgraded to persistent TCP connection of general use.

In our experience and in comments on Internet, we detected one
weakness and  criticis which restricts even wider adoption of the
protocol on Internal Networks: The mandatory masking of the frames
sent from client to server, as explained in Section 5.3. of the RFC,
titled Client-to-Server Masking.

Every frame sent from client to server needs to carry additional 4
bytes on the header. Frame payload must be "XOR"ed with this 4 bytes
prior being sent to server. And server must repeat this process as
described in RFC Section 5.3.

XOR Masking is developed for security reasons for communications on
Internet over proxies. It may be acceptable on public Internet. But
there is no logical reason to force XOR masking which implies extra
data overhead and extra CPU power on "trusted" networks, where, there
is no proxy usage.

But, there is no mechanism to disable masking on WebSocket RFC.
>From server to client communication without mask is allowed.
But, unfortunately, RFC forbids communications without mask bit set,
from client to server by
explicitly stating: "A masked frame MUST have the field frame-masked
set to 1 as defined in Section 5.2."

We propose adding a new extension to disable masking:

On negotiation request, client sends an extra http header, as
described in RFC 6455 Section 9.1:

Sec-WebSocket-Extensions: NoXorMask

When server receives this extension request, it will check whether it must

allow it or not.

And if it accepts, it sends back the same header on handshaking response:

Sec-WebSocket-Extensions: NoXorMask

And then, the rest of the websocket communication will continue without setting

"Masked" bit of frame header.

But if, server decides to not to allow communication without mask from client to

server, it simply ignores Sec-WebSocket-Extensions: NoXorMask header
and websocket

communication continues exactly as described in RFC 6455.



Note:

We implemented this extension in our in-house web server and it runs
successfully.

But this is still a draft.

We haven't sent it yet to IETF.

Comments, suggestions and English language corrections

and especially IETF style corrections are welcome.

Ismail Kizir


More information about the cryptography mailing list