[Cryptography] RFC for a websocket extension concerning also security

[Ismail Kizir]

Hello Bertrand,

Thank you for your contribution.
The link I am reading the copy of RFC 6455 is:

https://tools.ietf.org/html/rfc6455#page-32

At the end of page 31, it states:

"5.3.  Client-to-Server Masking

   A masked frame MUST have the field frame-masked set to 1, as defined
   in Section 5.2."

And at page 28, it states:

"... Mask: 1 bit

      Defines whether the "Payload data" is masked.  If set to 1, a
      masking key is present in masking-key, and this is used to unmask
      the "Payload data" as per Section 5.3.  All frames sent from

      client to server have this bit set to 1."

At page 50, Section 10.3 states the reason of masking and related attacks

One thing is interesting: I am nearly sure that I've read a more rigid
version of websocket RFC stating: "When server receives a non-masked
frame, it must immediately close the connection etc.etc."
I am nearly sure, because, I took that line as a comment in my code. I
was closing connection as per RFC.
And then, I've decided to write this extension.
But now, in current RFC, I can't see such a rigid statement. Maybe, it
was on drafts. If true, this may also be the proof of author's
intention to leave room for extensions like the one I am proposing.

Regards
Ismail

On Wed, Nov 23, 2016 at 6:52 AM, Bertrand Mollinier Toublet
<bertrandmt at gmail.com> wrote:
> Ismail, I took the time to read the relevant sections of RFC 6455. In particular, I do not read section 5.3 as requiring that client to server frames be masked. So you should have no problem keeping masking off for your use case.
>
> If you think I am misunderstanding, can you quote the exact passage which you read as mandating frame masking for client to server communication?
>
> --
> Bertrand Mollinier Toublet
>
>> On Nov 20, 2016, at 23:04, Ismail Kizir <ikizir at gmail.com> wrote:
>>
>> Hello everybody,
>>
>> I don't know if this may be considered as off-topic.
>> But it concern a security issue.
>> So, I wanted to write here before submitting in order to
>> collaboratively discuss the subject.
>>
>> We, all have custom protocols for our in-house applications and
>> servers. So I have.
>> But I also like standards. Websocket protocol is easily extendible.
>>
>> WebSockets, described in RFC 6455
>> (https://tools.ietf.org/html/rfc6455#page-32), is a robust, extensible
>> and widely accepted standard.
>> So, I converted all my existing protocol to work on top of websocket
>> protocol, as extensions.
>>
>> But I noticed some unnecessary performance and data overhead with 4
>> bytes XOR masking value:
>>
>> Section 5.2 defines the XOR masking and Section 5.3 mandates use of
>> XOR masking from client to server.
>>
>> I don't want to discuss here, the reasons for XOR masking from client
>> to server. They say, with some older proxies or with some malicious
>> intermediaries, it is possible to realize some attacks.
>>
>> But, usually, such protocols work on Intranets, not Internet. For
>> example, all my BigTable server impelentation communication is on my
>> private Internet. I am sure of it when I connect it. It is my own
>> private intranet and I know absolutely there is not any kind of proxy
>> involved.
>>
>> I am sure many other developers will think the same: Why paying the
>> cost of extra 4 bytes data overhead and extra cpu cycles to
>> mask/unmask data?
>>
>> So, I created a new websocket extension:
>>
>> On handshake, I sent one extra header from client to server:
>>
>> Sec-WebSocket-Extensions: NoXorMask
>>
>> And server checks the connection and decides what to do: If it is an
>> internet ip(which, in my case is impossible, since intranet is
>> protected by a firewall),  it accepts the offer sends back:
>>
>> Sec-WebSocket-Extensions: NoXorMask
>>
>> Then, the communication continues without mask bits set. No
>> unnecessary XOR mask data overhead and no wasted CPU cycles.
>>
>> I want to submit this is an RFC proposal.
>> But the main RFC document 6455 mandates the use of XOR masking in Section 5.3.
>>
>> I haven't a previous experience in writing RFC submissions.
>>
>> Such a contradiction with main standart may be allowed in extensions
>> written for that RFC?
>>
>> Is it a good idea to submit this extension as an RFC?
>>
>> May there be any security holes that I couldn't realize?
>>
>> Any comment, help, suggestion, English grammar/sentence
>> corrections/reorganisations are wellcome :)
>>
>> Regards
>> Ismail Kizir
>> _______________________________________________
>> The cryptography mailing list
>> cryptography at metzdowd.com
>> http://www.metzdowd.com/mailman/listinfo/cryptography