Subject: [hybi] Simple payload masking

From: Paul Colomiets <[email-masked]>
Date: Tue, 21 Dec 2010 05:02:32 +0200

Hi,

Can we assume that data, sent by browser must be a valid utf-8?
I think we can (and leave non-text packets to non-browser usage).

Then I propose to add a single byte payload mask at start of each
packet. Then each byte in packet will be XORed with mask byte.
It will be much simpler to implement and will use less cpu than
AES encryption.

While I think that simple mask like 0xC0 (or probably anything
with two high bits set) will make any valid UTF-8 string unable
to produce "\r\n\r\n" or even "\n\n" (because no two subsequent
bytes in UTF-8 can start with two high bit sets). It's better to
leave that byte to client implementors. Than, non browser clients
could set mask byte to zero. Browsers can inspect message to
be sent and make it the least http-like as it can.

Probably some rules for browsers must be figured out and
included into specifications to help browser implementors
to get it right.

Since malicious web server controls anything it sends anyway,
I don't see reasons to restrict web servers for any specific
mask value (or using mask at all). But I think it should be
included just for protocol symmetry, even if it's usually would
be zero. Same applies to secure version of protocol.

--
Paul

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Mon, 20 Dec 2010 19:22:55 -0800

No, we already said a while ago that we wanted to support binary from
browser.

On Mon, Dec 20, 2010 at 7:02 PM, Paul Colomiets <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 21 Dec 2010 04:33:28 +0100

>I think we can (and leave non-text packets to non-browser usage).

I think browser vendors do want to support binary data, what's stopping
them is mostly the lack of an agreed-upon general purpose data type for
binary data in JavaScript, but that is being worked on as a number of
other technologies also need such a type.

>It will be much simpler to implement and will use less cpu than

As far as masking goes, the security depends on the secrecy of the key
and the length of the key. As it has been proposed, AES is used only to
generate a keystream; applying it is simply a matter of XORing the
plaintext with the keystream. So long as the attacker cannot learn the
key and adapt the data he is sending to it, it does not matter how the
key is generated, so if you do per-frame masking there is no need to use
AES. What you do need is more key data than a single byte as otherwise
brute force attacks would be possible. (For arbitraty data that is, for
plain text there are indeed other options).
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Mon, 20 Dec 2010 19:39:12 -0800

> other technologies also need such a type.
I'd say what's stopping us is the handshake at the moment. We have
ArrayBuffer etc that we can use for binary data in JS now, so I don't really
think that's holding us back. It's more the wanting to get the handshake
issue sorted out first.