[Cryptography] RFC proposal draft text
ikizir at gmail.com
Mon Nov 21 08:56:40 EST 2016
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
Websocket-Extension: NoXORMask RFC Draft
Websocket is a robust, general, widely accepted and adopted
communication protocol described in RFC 6455
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:
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:
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
communication continues exactly as described in RFC 6455.
We implemented this extension in our in-house web server and it runs
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.
More information about the cryptography