Subject: [hybi] Masking alternatives: consensus declaration

From: Salvatore Loreto <[email-masked]>
Date: Wed, 13 Apr 2011 21:31:19 +0200

Hi there,

Thanks everybody for your participation in the "Masking alternatives" 
discussion
and for providing feedback on alternatives.

We have highly appreciated the fact that people have shown a great deal 
of flexibility in this respect.
Folks do have preferences (sometimes strong) one way or the other,
but have expressed that they could live with the other.
This is essential in terms of the larger practical issue of needing to 
resolve issues,
and moving on towards a protocol version that is stable enough for 
working group last call.
In light of this mail discussion, the Prague meeting and other side mail 
threads,
Gabriel and I, as wg chairs, are declaring a rough consensus on option 
#2 (masking-after-length).

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-------+-+-------------+-------------------------------+
      |F|R|R|R| opcode|R| Payload len |    Extended payload length    |
      |I|S|S|S|  (4)  |S|     (7)     |             (16/63)           |
      |N|V|V|V|       |V|             |   (if payload len==126/127)   |
      | |1|2|3|       |4|             |                               |
      +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
      |     Extended payload length continued, if payload len == 127  |
      + - - - - - - - - - - - - - - - +-------------------------------+
      |                               |         Masking-key           |
      +---------------------------------------------------------------+
      |    Masking-key (continued)    |         Extension data        |
      +-------------------------------+ - - - - - - - - - - - - - - - +
      :                                                               :
      +---------------------------------------------------------------+
      :                       Application data                        :
      +---------------------------------------------------------------+

Our reading of the list discussion is that WG participants prefer option #2 because:

1. It allows for better scalability in intermediaries as they do not
need necessarily to unmask the header unless they want to begin frame
inspection and processing.

2. It allows for a slightly less complex software design.

3. It paves the way for improved per-frame compression later on to be
applied on the payload before masking.

4. The additional attack vector via exposure of the bits in the header
is thought to be minimal.

cheers
Gabriel and Salvatore

---

From: Brian <[email-masked]>
Date: Wed, 13 Apr 2011 12:44:28 -0700

WooHoo!!

Thanks, all, for making this a reality!

Brian

On Wed, Apr 13, 2011 at 12:31 PM, Salvatore Loreto
<[email-masked]> wrote:
> We have highly appreciated the fact that people have shown a great deal of
> flexibility in this respect.
> and moving on towards a protocol version that is stable enough for working
> group last call.
>
> Gabriel and I, as wg chairs, are declaring a rough consensus on option #2
> (masking-after-length).
>
>       0                   1                   2                   3
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: David Endicott <[email-masked]>
Date: Wed, 13 Apr 2011 16:05:42 -0400

Don't you mean....

Masking Key:  WooHoo!!

Content: 03 07 0E 26 04 1C 0D 01 36 03 03 64 4F 09 4E 53 77 02 0E 23 06 01
46 01 23 07 06 3B 4F 0E 01 53 32 0E 03 21 1B 16 00

On Wed, Apr 13, 2011 at 3:44 PM, Brian <[email-masked]> wrote:

> working
> > Our reading of the list discussion is that WG participants prefer option
> #2
> > because:
> >

---

From: Brian <[email-masked]>
Date: Wed, 13 Apr 2011 13:24:12 -0700

No, I suppose I mean:

Masking Key: 03 07 0E 26
Content: 54 68 61 6E 6C 68 2F

Brian

---

From: David Endicott <[email-masked]>
Date: Wed, 13 Apr 2011 16:32:13 -0400

Masking Key: 00 00 00 00

Content:  49 6E 64 65 65 64 2E 20 20 41 6E 64 20 72 65 6D 65 6D 62 65 72 20
6E 6F 74 20 74 6F 20 75 73 65 20 6C 61 6D 65 20 6D 61 73 6B 69 6E 67 20 6B
65 79 73 2E

---

From: Brian <[email-masked]>
Date: Wed, 13 Apr 2011 13:38:46 -0700

Indeed!

#!/usr/bin/env node

var data="49 6E 64 65 65 64 2E 20 20 41 6E 64 20 72 65 6D 65 6D 62 65
72 20 6E 6F 74 20 74 6F 20 75 73 65 20 6C 61 6D 65 20 6D 61 73 6B 69
6E 67 20 6B 65 79 73 2E";
var bytes = data.split(' ').map(function(byte) {
    return parseInt(byte, 16);
});
console.log((new Buffer(bytes)).toString('utf8'));
// Indeed.  And remember not to use lame masking keys.

On Wed, Apr 13, 2011 at 1:32 PM, David Endicott <[email-masked]> wrote:
>> >> >      | |1|2|3|       |4|             |
>> >> > |
>> >> >      |                               |         Masking-key
>> >> > |
>> >> >      :
>> >> >                          :
>> >> >      :                       Application data
>> >> > :