Subject: [hybi] call for feedback on Masking alternatives

From: Salvatore Loreto <[email-masked]>
Date: Mon, 4 Apr 2011 16:22:48 +0300

(as HyBi wg co-chair)

Hi there,

Last Tuesday, during the HyBi wg session at the IETF meeting, we 
discussed the masking issue.

Based on that discussion, the decision is **only between two alternatives**:
whether to (1) mask the entire frame, as in the current 06 spec,
or to (2) mask only after the op codes and length.

In the wire format for (1), the 32-bit masking-key appears first, and 
then the entire frame masked (as in 06):

       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
      +---------------------------------------------------------------+
      |                       Masking-key                             |
      +-+-+-+-+-------+-+-------------+-------------------------------+
      |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  |
      + - - - - - - - - - - - - - - - +-------------------------------+
      |                               |         Extension data        |
      +-------------------------------+ - - - - - - - - - - - - - - - +
      :                                                               :
      +---------------------------------------------------------------+
      :                       Application data                        :
      +---------------------------------------------------------------+

In the wire format for (2), the masking-key appears after the op codes 
and length fields.
This is where 06 shows the "Extension data". The extension data and the 
rest of the frame would be shifted 32 bits and it would all be masked.

       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                        :
      +---------------------------------------------------------------+

In both cases, everything after the Masking-key is masked.

Several folks have already expressed themselves on this issue either 
recently on the mailing list, or in person at the IETF meeting this week.

Gabriel and I, as HyBi wg chairs, would like to solicit only those who 
have not yet expressed themselves on this issue, to do so now.

We will wait for additional feedback **until Friday April 8**, and based 
on the feedback will make a decision shortly afterward.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: David Endicott <[email-masked]>
Date: Mon, 4 Apr 2011 09:49:53 -0400

To be officially on record:

+1  for alternative:  (2) mask only after the op codes and length.

On Mon, Apr 4, 2011 at 9:22 AM, Salvatore Loreto <
[email-masked]> wrote:

>  (as HyBi wg co-chair)
>
>
> Hi there,
>
> Last Tuesday, during the HyBi wg session at the IETF meeting, we discussed
> the masking issue.
>
> In the wire format for (1), the 32-bit masking-key appears first, and then
> the entire frame masked (as in 06):
>
>       0                   1                   2                   3
> In the wire format for (2), the masking-key appears after the op codes and
> length fields.
> Gabriel and I, as HyBi wg chairs, would like to solicit only those who have
> not yet expressed themselves on this issue, to do so now.
>
> Salvatore Loretowww.sloreto.com
>
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: "Joonas Lehtolahti" <[email-masked]>
Date: Mon, 04 Apr 2011 18:39:33 +0300

Personally I can live with either approach but I have preference for  
format (2).

Cheers,

Joonas

---

From: John Tamplin <[email-masked]>
Date: Mon, 4 Apr 2011 11:42:51 -0400

> or to (2) mask only after the op codes and length.

I personally am fine with either - to me the pros and cons for either option
seem balanced.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Scott Ferguson <[email-masked]>
Date: Mon, 04 Apr 2011 09:31:49 -0700

> Personally I can live with either approach but I have preference for 

+1

same here

-- Scott

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 4 Apr 2011 20:27:22 +0200

+1

same here too.

Willy

---

From: Bruce Atherton <[email-masked]>
Date: Mon, 04 Apr 2011 16:28:18 -0700

I have a strong +1 preference for option 2, though if option 1 won out I 
could live with it.

I hate how I have masking coded now and really want to recode it to look 
like an extension, even though it isn't really one. With the second 
option to the machine that is a difference that isn't a difference.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 05 Apr 2011 12:00:44 +0900

Same here.   Regards,   Martin.

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 5 Apr 2011 12:13:50 +0900

> or to (2) mask only after the op codes and length.

I can live with either.

Takeshi

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 5 Apr 2011 15:19:32 +1000

+1 for option (2)

---

From: "Simon Pieters" <[email-masked]>
Date: Tue, 05 Apr 2011 10:41:53 +0200

> then the entire frame masked (as in 06):

I prefer option 1 on the basis that an attacker has less control over the  
bits that go over the wire. It's not enough bytes to pull off the cache  
poison attack, but it might be enough to pull off a different attack that  
we are unware of today. However, I can live with option 2 if the WG  
decides to go with that. (If we find that option 2 has a security problem  
in the future because the attacker can contorl the length bytes, we can  
always require that browser clients always fragment at into two fragments  
at a random position when length is greater than 64k or so.)

-- 
Simon Pieters
Opera Software

---

From: Roberto Peon <[email-masked]>
Date: Tue, 5 Apr 2011 01:57:31 -0700

I prefer option 2.
-=R

---

From: Justin Lee <[email-masked]>
Date: Tue, 5 Apr 2011 13:11:08 -0400

I prefer option 2 as well.

-- 
You can find me on the net at:
http://antwerkz.com
http://www.linkedin.com/in/justinlee
http://www.twitter.com/evanchooly

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 05 Apr 2011 18:25:37 +0100

Salvatore Loreto wrote:

> Based on that discussion, the decision is *only between two alternatives*:

I prefer option 1.

---

From: "Greg Longtin" <[email-masked]>
Date: Tue, 5 Apr 2011 17:33:34 -0500

> or to (2) mask only after the op codes and length. 

I vote for #1

Based on

1. The (possibly unfounded) belief that it may improve security.

2. My server code (and other's also) works with #1.  Yes, selfish.

Greg Longtin

---

From: Brian McKelvey <[email-masked]>
Date: Tue, 5 Apr 2011 15:37:22 -0700

I'm implementing my server to support #1 to comply with the current draft but I can't wait until I can modify it to use #2.  :)

Brian

Sent from my iPhone

---

From: Anthony Catel <[email-masked]>
Date: Wed, 06 Apr 2011 00:42:27 +0200

I also vote for #1 because I'm too lazy to rewrite my code ;) and see no 
reason to favor #2

---

From: "Greg Longtin" <[email-masked]>
Date: Tue, 5 Apr 2011 17:56:20 -0500

Brian,

> > I'm implementing my server to support #1

It's trivial for a packet with one message, gets a little worse for a packet
with multiple messages.

Using Minefield on v06, and Safari and Chrome 11 on v76 (v00?), I get very
few 'combined' messages.  Using IE9 with Silverlight, a fair number of
packets combining two messages.

I'm testing with clients sending messages at a rate of about 30 per second.

Thanks,

Greg Longtin

---

From: Brian McKelvey <[email-masked]>
Date: Tue, 5 Apr 2011 16:26:05 -0700

From my experience implementing this masking (I presume you're talking about #1, masking everything including the framing) I don't see any change in difficulty whatsoever relating to handling multiple messages in a single packet.  I wrote my code to handle that from the beginning.  And handling multiple messages per packet or handling single messages that span multiple packets isn't related to the masking in the first place.  Have I misunderstood you?

Brian

Sent from my iPhone

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 06 Apr 2011 01:43:26 +0200

>have not yet expressed themselves on this issue, to do so now.

We have masking to make it easy to explain how cross-protocol attacks
are mitigated: attacker-controlled bits are unpredictably masked, so
an attacker cannot force interesting byte sequences on the wire. That
is the first option in the poll.

The second option turns this into "well we kinda hope nothing can be
done by letting attackers control some of the bytes, so we allow to
control those, but allowing control over too many bytes is kinda bad,
so other bytes we allow only very limited control over".

There were some interesting discussion how masking interferes with a
couple of things, but later this turned "bad protocol design", "lack
of options to turn to stronger masking schemes" and a bag of other
arguments that I found very uninteresting, to but it that way.

My impression is that most people hate this whole masking business so
given the chance to ease the pain they vote to do just that, but I do
not find that supported by particularily good reasoning. (Others just
now vote for the first option because that's what they implemented,
which is also poor reasoning giving the effort required to change.)

(I do not particularily like the frame layout and extension design in
general and would be quite glad to look at ways to make things look
less ugly, but I see little reason to consider this for masking in i-
solation.)

It seems to me that the odds of an attack working diminish with the
length of the frame, as such the most crucial part to mask would seem
to be the very first bytes, so I do not quite understand why there is
no option, if you don't mask the "header" bits, to at least put the
mask before the frame header.

Well. The second option makes it harder to explain the security
properties of the protocol, so, all else the same, that is not my
preference.
-- 
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: Greg Wilkins <[email-masked]>
Date: Wed, 6 Apr 2011 15:32:36 +1000

On 6 April 2011 09:43, Bjoern Hoehrmann <[email-masked]> wrote:
> not find that supported by particularily good reasoning.

Please don't make sweeping statements regarding the validity of how
people have determined their preference in this poll. I think that we
are all capable of weighing up the pros and cons of options and making
reasoned decisions based on our own experiences and views.   Just
because somebody weighs the options and comes up with a different
preference to you does not mean you should question the validity of
their reasoning.

> (Others just  now vote for the first option because that's what they implemented,

If somebody does not have strong preference one way or the other, then
choosing the option that they have already implemented is an entirely
valid and sensible preference.

I fully accept that my preferred option is a little weaker with
regards to protecting from attacks on intermediaries. But my judgement
on all the information provided here is that is only a tiny weakness
to a vanishingly small attack vector, which if it ever proves to be a
problem can be addressed by numerous other mechanism and thus it is a
reasonable price to pay for clear framing and the benefits that
brings.    Your judgement obviously is different to mine, but I'm not
questioning your reasoning - I accept that it must only be because the
reason I and others have given are not compelling enough for you.
Extend us the same benefit.

---

From: Andy Green <[email-masked]>
Date: Wed, 06 Apr 2011 10:05:58 +0100

> I also vote for #1 because I'm too lazy to rewrite my code ;) and see no

Well you're welcome to your opinion, but about reason to consider #2 you 
might like to think about what happens in the mux extension.

Obviously, it has to put a mux uber-framing around existing websocket 
content to do the mux action.  John's draft allows muxing of 
already-muxed streams.

In the case the websocket framing about length is obscured and #1 stays, 
muxed content looks like

  <mux uber framing telling data follows with no length indication>
    [impenetrable randomness of unknown length unless fully and 
recursively parsed]

-Andy

---

From: "Greg Longtin" <[email-masked]>
Date: Wed, 6 Apr 2011 08:19:26 -0500

Bjoern,

> (Others just now vote for the first option because that's what they
> implemented, which is also poor reasoning giving the effort required
> to change.)

> It seems to me that the odds of an attack working

I am not familiar with any of the possible attack vectors, nor am I familiar
with masking's effect on intermediaries.  As an aside, if anyone knows of
any good links with 'introductory' material on those subjects, please let me
know.

My vote was not for "that's what they (I) implemented", but what I assume
was a past decision based on good reasoning.

Thanks,

Greg Longtin

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 6 Apr 2011 21:06:17 +0100

>    [impenetrable randomness of unknown length unless fully and 

Unwanted side effect: Delivery timing delays when the muxer does not
distinguish underlying message boundaries from mid-message bytes.

Either it forwards every byte eagerly, which causes excessive mux
chunks and TCP packets, and TCP timing degrades due to mixed size
segments, or it delays slightly to buffer more before fowarding, and
adds delays that way.

-- Jamie