Re: [hybi] Masking only Payload/Extension Data

[Andy Green <[e-mail]>]

On 03/10/2011 03:04 PM, Somebody in the thread at some point said:

Hi -

>> I suspect most would agree that masking of everything is better than
>> stalling the protocol any longer, but if Adam is the only objector and
>> the browser folks are okay with masking only payload then perhaps we
>> should move forward with it.
>
> I object too. I think not masking the header gives up a minor security
> benefit for an insubstantial benefit. None of the arguments about the

It is much cleaner protocol-wise to have consistent framing and mask 
inside the extension area and allows server traffic masking to be 
selected the same way.

Once that's done, if 4-byte recirculating xor with per-frame random key 
isn't enough, and we have been told it is not "enough" before if you 
recall, then it'll be easy to upgrade the protocol to use AES masking or 
whatever without breaking the framing.

> benefits of the change have convinced me they add up to very much.

To be fair these are mainly defending the idea of masking as a whole, by 
explaining that it is cheap -->

> http://www.ietf.org/mail-archive/web/hybi/current/msg06689.html
> http://www.ietf.org/mail-archive/web/hybi/current/msg06705.html
> http://www.ietf.org/mail-archive/web/hybi/current/msg06718.html

That's not really the issue, the issue is do we really impact these 
security concerns by letting what is often just two bytes but may extend 
to ten structured bytes with opcode + length in go out unmaksed.

What in fact does your Mozilla implementation do about breaking large 
messages into CONTINUATION?

As a sort of side note, since you have been supporting protecting these 
alleged vulnerable proxies, do you have any effort or interest in any 
effort to actively detect and identify them, maybe a fuzzing tool for 
content?  It's curious there's so much handwringing about these alleged 
vulnerable intermediaries but actually I didn't see anyone give a toss 
about finding them until now.

-Andy