Subject: [hybi] Straw-poll on Masking options

From: Salvatore Loreto <[email-masked]>
Date: Wed, 12 Jan 2011 21:00:35 +0100

Hi all,

Masking from the client to the server
has reached strong consensus within this wg as a mechanism to reduce 
security risks.

However there is disagreement on the actual method for masking.
The technical differences, pro and cons, advantages and disadvantages,
as well as the legal implications of each method have already been 
deeply discussed.

In order to settle the question of masking and find a way forward that 
has a wide acceptance,
Joe and I, as HyBi chairs, want to check where the consensus is
on the following relevant options that have been discussed (and 
summarized at
some point in the mailing list by Eric Rescorla)

1. a fixed mask carried entirely in the packet.

2. A longish repeated mask computed from the packet. For concreteness,
    suppose HMAC-SHA1(<uuid>, <server-conn-key> || <client-conn-key> || 
<packet-key>), but
    obviously there's flexibility here.

3. A fully generated mask (if so specify also what you would like to use 
e.g. AES-CTR or HMAC-SHA).

Please indicate your preference(s) or the one can meet your bar for "I 
could live with that";
In the case you have more then one, please put the choices in a 
preference order.

This poll will run until January 18th.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: John Tamplin <[email-masked]>
Date: Wed, 12 Jan 2011 15:08:06 -0500

On Wed, Jan 12, 2011 at 3:00 PM, Salvatore Loreto <
[email-masked]> wrote:

> as well as the legal implications of each method have already been deeply
> discussed.
>
> In order to settle the question of masking and find a way forward that has
> a wide acceptance,
> on the following relevant options that have been discussed (and summarized
> at

I assume one operation per frame to generate a mask, and then do the same as
in #1?

> In the case you have more then one, please put the choices in a preference
> order.
>

Any of the above are fine with me personally.

I prefer the minimum overhead to satisfy all participants, so my order would
be #1, #2, #3.  In the case of #3, I prefer fewer external dependencies and
export issues, so I would prefer to avoid AES though if it is a lot faster
than HMAC-SHA1 then I could be persuaded.

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

---

From: Adam Barth <[email-masked]>
Date: Wed, 12 Jan 2011 13:22:41 -0800

On Wed, Jan 12, 2011 at 12:00 PM, Salvatore Loreto
<[email-masked]> wrote:
> In order to settle the question of masking and find a way forward that has a
> wide acceptance,

This option is ok, but less than ideal.

> e.g. AES-CTR or HMAC-SHA).

This is the best option.

> Please indicate your preference(s) or the one can meet your bar for "I could
> live with that";
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 12 Jan 2011 22:42:11 +0100

> 1. a fixed mask carried entirely in the packet.

I vote for this one above, which we can improve with a changing mask
so that the attacker cannot know the relations between bytes in advance
if some prefer it..

>    obviously there's flexibility here.

Definitely not this one, it's far too slow on small frames.

> e.g. AES-CTR or HMAC-SHA).

Warning, there were two proposals for this one. The first one which does
not offer better protection than #1, and the second one which requires
servers and intermediaries to *bufferize all the frame* before being
able to decipher it, which is very expensive on medium-sized frames,
and not possible at all for large ones (up to 2^63 bytes).

While I could probably live with the first version, I'd definitely
reject the second proposal which cannot reasonably be implemented
at all.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 12 Jan 2011 23:12:06 +0100

> e.g. AES-CTR or HMAC-SHA).

BTW Sal, could we list Base64 (or any equivalent CRLF-less masking) that
very few of us have already evocated here ?

It is the only solution to be _certain_ to definitely get rid of the
issue we're talking about, has much less CPU overhead than AES/HMAC,
at the expense of higher network costs (+14-33% for the simplest
versions, even less with escaping).

I'd personally use the fixed mask over base64, but would a lot prefer
base64 over crypto algorithms. I don't know others' opinions, and maybe
in the end the network overhead would not be perceived as much of a
trouble as the downsides of the crypto algos.

Thanks,
Willy

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 12 Jan 2011 14:23:36 -0800

On Jan 12, 2011, at 12:00 PM, Salvatore Loreto wrote:

> has reached strong consensus within this wg as a mechanism to reduce security risks.
> 
> as well as the legal implications of each method have already been deeply discussed.
> 
> In order to settle the question of masking and find a way forward that has a wide acceptance,
> on the following relevant options that have been discussed (and summarized at

I can't live with this option. It does not address the HTTP vs. WebSocket threat model.

>   suppose HMAC-SHA1(<uuid>, <server-conn-key> || <client-conn-key> || <packet-key>), but

I can live with this option, but it's not my preferred choice. It has worse performance and slightly worse security properties than #3.

> 
> 3. A fully generated mask (if so specify also what you would like to use e.g. AES-CTR or HMAC-SHA).

This is my most preferred option. AES-CTR seems ok. I would also be ok with any well-known stream cipher.

> 
> 
> Please indicate your preference(s) or the one can meet your bar for "I could live with that";
> In the case you have more then one, please put the choices in a preference order.
>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 12 Jan 2011 23:36:33 +0100

> I can't live with this option. It does not address the HTTP vs. WebSocket threat model.

We should be careful not to conflate issues here. The masking was
never introduced for this purpose, you proposed to make use of it
to *also* address this threat.

But we should address issues one at a time. Right now masking has
been proposed as the solution to prevent a server from making a
client emit a WS stream that could be interpreted by a caching
intermediary as a valid HTTP request.

The HTTP vs WS threat model was addressed a long time ago with the
handshake, but apparently you have discovered issues that were not
discovered by then. Thus we should probably revisit them and see
how to fix them.

Thanks,
Willy

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 12 Jan 2011 14:40:56 -0800

> intermediary as a valid HTTP request.

I prefer the design that addresses more distinct attacks. This straw poll is about what masking algorithm to choose, not about how to address one specific attack. The preferences of many WG members will be based on factors that don't relate to security at all. So while you are free to disagree with my reasoning, I don't think it's fair to call it out of bounds for this poll.

Also, I have no desire to cause yet another round of changing the masking. Let's pick the right one this time, and not thrash.

> discovered by then. Thus we should probably revisit them and see

I've explained in detail how masking that folds in a server nonce is a more robust defense multiple times, including in the past few days.

Regards,
Maciej

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 13 Jan 2011 00:00:01 +0100

> I prefer the design that addresses more distinct attacks. This straw poll is about what masking algorithm to choose, not about how to address one specific attack. The preferences of many WG members…

I do think that because it's mixing solutions while maybe it is
not required.

> Also, I have no desire to cause yet another round of changing the masking. Let's pick the right one this time, and not thrash.

Then better delay the poll until we're sure that it's the masking that
must address the issue you've raised ?

> I've explained in detail how masking that folds in a server nonce is a more robust defense multiple times, including in the past few days.

I personally have no objection against the XOR mask involving either or
both nonces provided that it only applies to payload, so as not to make
multiplexing impossible later.

Regards,
Willy

---

From: Dave Cridland <[email-masked]>
Date: Wed, 12 Jan 2011 23:17:02 +0000

> has reached strong consensus within this wg as a mechanism to  

I'm not clear how you can make the call that this is strong  
consensus, but still.

I can live - under protest - with something based on XOR with a  
maximum keylength of 56 bits. In this instance I no longer care what  
method is used to derive the key, and more to the point nor will the  
regulatory bodies within the EU.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: John Tamplin <[email-masked]>
Date: Wed, 12 Jan 2011 18:27:19 -0500

> multiplexing impossible later.

I don't think applying the mask to the payload or the entire frame matters
regarding multiplexing - I believe the mux is going to have to unmask the
inner frames anyway [assuming they were masked at all - the initial use case
is a browser implementing muxing talking to a server (or frontend acting as
a server] that implements the MUX extension to reduce the number of
connections).

---

From: Scott Ferguson <[email-masked]>
Date: Wed, 12 Jan 2011 15:41:30 -0800

> has reached strong consensus within this wg as a mechanism to reduce 

Well, more like acceptable overkill to achieve consensus.

> 1. a fixed mask carried entirely in the packet.

This is fine.

> use e.g. AES-CTR or HMAC-SHA).

These add no actual security value for this issue.

-- Scott

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 13 Jan 2011 00:52:54 +0100

> a server] that implements the MUX extension to reduce the number of

Not necessarily John. Imagine for instance a mux which makes use of the
Host+path + maybe some other requests elements to aggregate multiple
streams over a single connection and forward it to a server. It will
know what stream goes where. However, if it wants to correctly
interleave frames, it must know their lengths, which means having
access to the framing (which almost only contains the length BTW).

Imagine you have two client streams A and B with frames numbered
1 to 4 of various lengths :

  A : 11222222222333333344444444444
  B : 11111122222222333333333333344

The mux would send that to C :

      A(11)B(111111)A(22222222222)B(2222222)...

This does not require decoding the payload though. However, if there is
no way to read the framing, multiplexing is not possible.

The only ones which will need to read the payload are the ones which
will accept the connection on behalf of the server. Since they will
share nonces with the client, if the keying depends on nonces, then
it will have to decode on one side to recode on the other one, which
becomes quite inefficient.

Regards,
Willy

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 13 Jan 2011 08:05:33 +0800

On 2011-01-13 at 09:23:36, Maciej Stachowiak wrote:
> I can live with this option, but it's not my preferred choice. It has
> worse performance and slightly worse security properties than #3.

I don't see how generating one HMAC per frame is going to be less efficient than generating n bits.  On very small (20 byte) frames, sure, but overheads are going to kill performance on those anyway.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Jan 2011 00:10:16 +0000

This relfects my position as well.

I would prefer AES but can live with any plausible PRF-looking thing

-Ekr

---

From: John Tamplin <[email-masked]>
Date: Wed, 12 Jan 2011 20:14:53 -0500

> becomes quite inefficient.

The problem is that the MUX'd frame will itself be masked, so you are
double-masking it.  If you allow that on the grounds it is cheaper than
recoding it, then you impose a cost on the MUX-in-the-client case for having
to multiply encode each logical channel's frames, which I think is going to
be far more important (at least in the near term).

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 13 Jan 2011 04:58:30 +0100

>However there is disagreement on the actual method for masking.

We disagree about the requirements our protocol design needs to meet. We
have some who find very simple schemes sufficient, others find them in-
sufficient. As far as I am aware, the latter group has not been able to
point out any software that has the combination of bugs that would give
cause to worry. They have not been able to cite an argument why such a
software would be deployed in notable numbers. They have not been able
to point out an attack that would make the simple schemes considerably
weaker than the more elaborate schemes. Nor have they shown that even if
we took all those things for granted that more elaborate masking schemes
are the best way to address "the problem". [1]

If there is something resembling rough consensus that more than simple
schemes offer needs to be done, we can figure out what the best way to
accomplish that is. If there is rough consensus in the other direction
we can make an effort to better understand the concerns and look for
other ways to address them if the concerns are unpersuasive. If the
concerns turn out to be persuasive, all the better.

I don't think running this poll and then seeing, say, well most people
prefer the very simple scheme, so let's ignore the concerns raised and
get this done, or seeing, well, round about everybody could live with
the "hash" option so let's just say run SHA-1 over the key and call it
a day, would lead to the best protocol design here, nor would it help
much to get something out "in time".

So I will not be participating in this poll.

[1] Given how ... unconvincing the concerns have become at this point
    I actually did investigate a similarily ... unconvincing solution
    http://lists.w3.org/Archives/Public/www-archive/2011Jan/0014.html

Well, off now; couple of years ago Microsoft sent me a free copy of the
Microsoft Press "Software Requirements" book; reading it again I will
either learn something new -- or won't feel bad throwing it at people.
-- 
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: "Martin J. Dürst" <[email-masked]>
Date: Thu, 13 Jan 2011 13:15:29 +0900

> 1. a fixed mask carried entirely in the packet.

My first preference is for a fixed mask per frame, directly visible at 
the start of the frame, derived from (possibly some server material and 
some client material and) some randomness, but not involving the packet 
data itself.
This seems to be potentially somewhat above a, but below 2. Please count 
this towards 1 and/or 2 depending on how the details turn out.

> e.g. AES-CTR or HMAC-SHA).

I won't die if the WG accepts this option, so in that sense, I have to 
admit "I could live" with it, but I'm extremely reluctant to agree to 
this. If in doubt, please count me out.

As a general comment, I have to say that this is the first protocol I 
know where there is talk about using data obfuscation in general and 
crypto in some variations in the non-secure version. Given the extremely 
long tradition of text-based application-level protocols in the IETF, 
and the very many advantages (debugging, education,...) of such 
protocols (probably underestimated by many because they are so obvious), 
I'm extremely reluctant to agree to anything that requires any state for 
decoding/inspecting packets.

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 13 Jan 2011 07:13:27 +0100

On Wed, Jan 12, 2011 at 08:14:53PM -0500, John Tamplin wrote:
> double-masking it.

No, that was not suggesting such a thing at all. I was really suggesting
that this component was forwarding frames that it has just interleaved.
However, if the encoding key cannot simply be adjuster per-frame, then
the mux has to decode+encode each frame. If the encoding is a simple XOR
and key is a derived from a random at the beginning of the frame and the
nonces, then the mux can still change it in each frame without having to
decode/recode.

Willy

---

From: John Tamplin <[email-masked]>
Date: Thu, 13 Jan 2011 01:28:11 -0500

> nonces, then the mux can still change it in each frame without having to

It seems clear that the consensus will be that servers accepting connections
from untrusted clients will refuse to accept unmasked connections.
 Therefore, the MUX->server frames must be masked.  Each frame can only have
one mask, therefore the mux'd frame cannot use the mask of any of the
embedded frames (plus current discussions would require them to use nonces
from each handshake, which would also prevent reusing one of the embedded
frame's masking).  Each of the mux's clients will also be masked with its
own key.  Therefore, either the mux must double-mask the embedded frame's
payload, or it must unmask and remask them.  Even if the mask is pure XOR
and it can modify the masked data, I would consider that still decoding
under the old mask and recoding under the new one.

I believe the most common use for multiplexing will be for a browser to
aggregate connections between tabs (and within a given tab, as an app may be
composed of separately written modules which use their own WebSocket
connections) to a single server.  In that case, it does not need to
unmask/remask the data, as the data is already unmasked -- instead, it
simply masks the entire mux frame.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 13 Jan 2011 07:39:43 +0100

> from untrusted clients will refuse to accept unmasked connections.

Agreed.

> Therefore, the MUX->server frames must be masked.

Agreed.

> Each frame can only have one mask, therefore the mux'd frame cannot use
> the mask of any of the embedded frames (plus current discussions would
> require them to use nonces from each handshake, which would also prevent
> reusing one of the embedded frame's masking).  Each of the mux's clients
> will also be masked with its own key.  Therefore, either the mux must
> double-mask the embedded frame's payload,

no, but below :

> or it must unmask and remask them.

Yes, that's what I was saying (or at least trying to say) !

> Even if the mask is pure XOR

Yes, or as I said, in this case, it's possible to change the masking
key at the beginning of the frame without touching the data :

   new_key = old_key ^ client_side_key ^ server_side_key;

> simply masks the entire mux frame.

At the beginning it might be the most common use, but quickly we'll
see for WS the same optimizers that exist with HTTP. The same causes
will cause the same effects. Having one million concurrent connections
to a thread app is not possible. Having them on a front proxy which
aggregates them over a few hundreds of connections is possible and
not much difficult. That's already how some large sites handle large
amounts of HTTP connections, despite the in-order design. With WS,
there will not even be the in-order issue which means that a very
low number of concurrent connections will suffice.

So I really predict that multiplexing at the front of server-side
infrastructure will quickly appear. And if we don't design it ourselves,
some will add their proprietary extensions to support it, and we'll see
some "Fast-WebSocket", "WebSocket-Express" or such things emerge with
their own API.

Regards,
Willy

---

From: John Tamplin <[email-masked]>
Date: Thu, 13 Jan 2011 01:59:05 -0500

>   new_key = old_key ^ client_side_key ^ server_side_key;

Ok, I see what you are saying now -- I agree that if this form of masking is
chosen you could simply alter the key for the logical channel frame and not
have to modify the payload bytes.

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 13 Jan 2011 11:41:35 +0100

Hi there

I have been asked to officially clarify option #3 (I will add the 
clarification in line below).

I want also invite people NOT to use this specific mail thread to try to 
convince each other
neither to discuss technicality of the different proposals on the table:
if you discussion please start a different thread for them.

On 1/12/11 9:00 PM, Salvatore Loreto wrote:
>      suppose HMAC-SHA1(<uuid>,<server-conn-key>  ||<client-conn-key>  ||
> <packet-key>), but
Clarification Note: "key at the end" / "buffer the whole frame"  are not 
intended for option #3

cheers
/Sal

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 13 Jan 2011 14:16:07 +0100

On 1/13/11 7:39 AM, Willy Tarreau wrote:
> infrastructure will quickly appear.
(as Individual)
I tend to agree on the Willy prediction,
especially in the Mobile Telco infrastructures that is something most 
likely to appear.

/Sal

>   And if we don't design it ourselves,

-- 
Salvatore Loreto
www.sloreto.com

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 14 Jan 2011 08:31:19 +1100

> 1. a fixed mask carried entirely in the packet.

This option is my strong preference.

> e.g. AES-CTR or HMAC-SHA).

I could only accept either of these options if there were a) no other
strong objectors; b) they were applied as optional extensions.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Jan 2011 22:43:31 +0100

On 13.01.2011 22:31, Greg Wilkins wrote:
> ...

+1

Disclaimer: I'm not an implementer (currently), nor a security expert.

On the other hand, I haven't been convinced that the problems more 
complicated approaches try to address are real (in the sense that 
Websockets need to solve them). As a matter of fact, I'm not even 
convinced that we need any masking.

That being said... minimally, it should be possible to inspect a message 
without having to keep state.

Best regards, Julian

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 13 Jan 2011 22:47:42 +0100 (CET)

+1

I do not think it has been shown that masking beyond this level is worth the 
added complexity.

-- 

  / daniel.haxx.se

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 14 Jan 2011 04:15:46 +0000

+1

Wouldn't just replacing all CRs and LFs with an escape sequence give
perfect security against HTTP injection/confusion attacks ...with
essentially no network, CPU or programming overhead?

Compared with 1, 2 or 3 which are still vulnerable to the attacks they
are designed to block, given enough connection attempts.

-- Jamie

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 14 Jan 2011 06:52:53 +0100

> essentially no network, CPU or programming overhead?

It would in fact be a trade-off between CPU overhead and network
overhead :
  - escaping 3 chars (CR, LF and the escape prefix) would provide
    the smallest network overhead but would require the CPU to
    parse all bytes when forwarding them because the length cannot
    be determined at the beginning

  - performing a fixed transform on the contents (base64/128)
    allows intermediaries to know in advance how many bytes need
    to be forwarded (once the frame has been decoded), but it
    implies higher networking overhead (+33/+14%).

> are designed to block, given enough connection attempts.

I'd say that it's cheaper than 2 or 3 CPU-wise and stronger at the same
time. In fact, it's provably secure as it's proved that you can't find
either a CR or an LF in a base64 sequence.

But I really think that for what we're trying to achieve, #1 is by far
enough, and even less expensive for the network and CPU.

Willy

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 14 Jan 2011 18:25:06 +1100

On 13 January 2011 09:12, Willy Tarreau <[email-masked]> wrote:
> issue we're talking about,...

well not the only solution.   The suggestion to fragment a frame when
ever a risky string is seen (eg HTTP) also works..... but
unfortunately does not fit the definition as a masking algorithm.

cheers

---

From: James Graham <[email-masked]>
Date: Fri, 14 Jan 2011 12:12:43 +0100

> 1. a fixed mask carried entirely in the packet.

I can't live with this as it doesn't have the desired security properties.

> obviously there's flexibility here.

This seems to be worse than #3 in significant ways. However it meets the 
"can live with" bar for me.

> e.g. AES-CTR or HMAC-SHA).

This is my preferred option.

---

From: "Pat McManus @Mozilla" <[email-masked]>
Date: Fri, 14 Jan 2011 12:50:51 -0500

> 2. A longish repeated mask computed from the packet.

> e.g. AES-CTR or HMAC-SHA).

My primary preference is for 1 which is sufficient to the job at hand -
if we can have consensus that it is good enough I would be content with
it. If that isn't enough, I can support #2 which is expensive but
tolerably so.

At this point #3 (AES) would be acceptable as a negotiated option with
#1 or more likely #2 as a required fallback. That approach would give
the camp that needs "at least #2" that level of randomness, while
allowing implementations who wished to deal with the regulations around
AES the capability of opting into something faster (assuming opted into
by both ends). Intermediaries not willing to do AES would obviously have
to participate in the negotiation, which all gets complicated.. so this
is my least preferred, yet acceptable, route.

---

From: Tomas Franzén <[email-masked]>
Date: Fri, 14 Jan 2011 19:09:02 +0100

+1

Finally a relatively nice solution. Base64 is simple, commonly used in other standards and a guarantee that the payload will never contain CRLF. The length overhead seems acceptable to me.

Tomas

---

From: Cedric Vivier <[email-masked]>
Date: Sat, 15 Jan 2011 02:53:19 +0800

> Finally a relatively nice solution. Base64 is simple, commonly used in other standards and a guarantee that the payload will never contain CRLF. The length overhead seems acceptable to me.

Sounds like it is reasonable AND actually take care of the original
problem.. which is to guarantee no intermediary will get tricked by an
evil HTTP-looking sequence of bytes in the packet.

By using XOR or AES, no matter how random our packets are, they will
eventually produce be a potentially dangerous sequence... if you
consider the possibility that a broken proxy has thousands of users
behind it, it's just a matter of time and amount of bytes before its
cache will be poisoned, no matter what.

Also the size overhead could be lesser by using Ascii85 rather than
Base64... and this would actually generate smaller packets in some
cases [1] where latency is important since the overhead of Ascii85 can
be lesser than the overhead of sending a new random key for each
packet.

[1] : WebSockets clients using the protocol for frequent updates
through [very] small packets (eg. interactive/real-time applications
such as games or collaborative writing...)

Regards,

---

From: Joshua Bell <[email-masked]>
Date: Fri, 14 Jan 2011 10:57:19 -0800

On Fri, Jan 14, 2011 at 10:09 AM, Tomas Franzén <[email-masked]> wrote:

> On 12 jan 2011, at 23.12, Willy Tarreau wrote:>
> Finally a relatively nice solution. Base64 is simple, commonly used in
> other standards and a guarantee that the payload will never contain CRLF.
> The length overhead seems acceptable to me.

If we're considering options that sacrifice message length for security, do
we also need to consider an option where the (unencoded) payload length is
sent as something other than a network-order 63-bit integer, to avoid
attacks where "GET /" is encoded into the length? Furthering the concession
of sacrificing frame length for simplicity+security, the length could be
sent as a 16-digit hexadecimal ASCII string. (More compact forms are of
course possible, such as a UTF-8-like encoding scheme for length where high
bits are set except for the trailing octet.)

The first octet of the data could be as per the -04 framing
(FIN/RSV1/RSV2/RSV3/opcode) as this is not under the control of the
browser-sandboxed attacker so it is not a concern, although for simplicity
extension data would follow this directly, with the caveat that the lead
octet + extension data can't look like "GET /"; this would be a requirement
that future extensions supported by browsers may have to honor.

Overall frame structure would be:

<framing octet> <extension data> <ASCII length> <base64-encoded payload>

For example the payload "Hello World" as a single fragment Unicode text
frame with no extensions (i.e. what browsers would be sending on behalf of
sandboxed script in the near term) would be sent as:

0x84 "000000000000000bSGVsbG8gV29ybGQ="

Long but simple.

-- Josh

---

From: Bruce Atherton <[email-masked]>
Date: Fri, 14 Jan 2011 11:37:10 -0800

I don't see why this has to be an either/or. My vote would be to support 
both option 1 and option 3. Option 1 as the default, option 3 (or 
base64, which I agree is a more secure option in this case) available as 
an extension.

Anyone writing a websocket client could choose to only implement the 
option 3 extension masking for sending data if they want to give such a 
preference to security. Anyone else could choose option 1 with its much 
lower barriers to entry.

If there can be only one masking algorithm, then my vote is for option 
1. There is one form of attack it does not address, but masking is not 
the only way, nor the best way I have become convinced, to protect 
against that attack.

The attack presupposes that setRequestHeader() is insecure in browsers, 
but getRequestHeader() is completely secure. I think fixing the browsers 
to make setRequestHeader() secure is a more desirable outcome than 
warping the protocol to get around this buggy behaviour. If not, then 
there are other solutions such as using HELLO frames. The cost of this, 
losing the ability to force the server to check that the client is 
authentic, is IMO trivial compared to the costs of losing the ability to 
debug streams in many situations, the loss of ubiquity for Websockets, 
and the vastly increased complexity of implementation. How many lines of 
C code with the standard library would a basic websockets client take 
with option 1? 100 at most? How many with options 2 or 3?

Can I live with options 2 or 3? I'm not slicing my wrists over any 
protocol. But if options 2 or 3 were the only one available, then for me 
Websockets would become a niche protocol, to be used only when 
constraints left me no other options, rather than a general tool to be 
considered anywhere a bidirectional client/server protocol was needed. 
The costs of adopting it would be too high for that.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 14 Jan 2011 21:33:04 +0100

On Fri, Jan 14, 2011 at 10:57:19AM -0800, Joshua Bell wrote:
> attacks where "GET /" is encoded into the length?

Cheap maskings such as XOR or Base64 can probably afford having the
framing masked. With XOR it's trivial, with Base64, we need to base64
decode the 2nd and third characters to know what framing length is
used. I agree it's not much convenient but still trivially easy to
do. Honnestly, I'd be more in favor of an even simpler encoding
algorithm. Base64 is for getting printable text. We don't need that,
we just need to avoid CRLFs. We could very well have a 7-to-8 bit
encoding where 7 bytes chunks are encoded in 8 bytes all having their
7th bit set, and where a premature end of frame could be indicated
with \0. Such an encoding is much cheaper than base64 since there's
no lookup at all and can be even cheaper on 64-bit machines that are
very common today, for instance something like this :

/* Decode 64 bits to 56 */
static inline uint64_t raw_to_wire(uint64_t in)
{
	int shift;
	uint64_t out = 0;

	for (shift = 0; shift < 56; shift += 7) {
		out += (in & 0x7F) << shift;
		in >>= 8;
	}
	return out;
}

Regards,
Willy

---

From: Roberto Peon <[email-masked]>
Date: Fri, 14 Jan 2011 12:51:57 -0800

> This option is my strong preference.

Ditto.
-=R

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 14 Jan 2011 13:01:23 -0800

Using more bandwidth to save CPU strikes me as a poor tradeoff. CPU speeds increase at a faster rate than network bandwidth, or for that matter memory bandwidth.

Regards,
Maciej

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 14 Jan 2011 22:08:44 +0100

> reject the second proposal which cannot reasonably be implemented

The more I'm thinking about it, the more I feel discomfort with those
masking options which consist in prepending random text at the beginning
of the frames.

The reason is simple : without this masking, the FIN bit prevents a
standard HTTP intermediary or server from seeing a request as the
beginning of the frames. I'm not discussing the ones that we'd like
to protect which supposedly skip the garbage, but the ones which don't
know about Upgrade+101 and which expect a second request. And we know
they exist.

With random at the beginning, even if it's the key, on average one
legitim connection in 4 billion *will* result in making a valid request
such as "GET\n" appear. So in fact, by trying to protect against a
supposed thread, we make another one appear where it would not have
otherwise.

I'll send a small proposal for an alternate masking method using 7-to-8
bits in a separate mail before the end of the poll. Maybe participants
will simply receive it with "pfff go away with your thing" but at least
I think we'll have explored quite a bunch of possibilities.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 14 Jan 2011 22:18:02 +0100

> Using more bandwidth to save CPU strikes me as a poor tradeoff. CPU speeds increase at a faster rate than network bandwidth, or for that matter memory bandwidth.

Sorry Maciej, but on this point I think you're wrong. Network speed increases
much faster than CPUs and that's even becoming an issue to process frames.

Some networks I saw migrate from 10 to 100 Mbps 12 years ago are now switching
to 10G, thus a 100x increase. The machines were quad-600 MHz Alphas, we're not
yet at 240 GHz in equivalent servers.

While derivates from Moore's law indicate performance doubling every 2 years,
some ISPs indicate that network bandwidth doubles every 9 months.

Regards,
Willy

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 14 Jan 2011 22:32:45 +0100

Please
do NOT use this specific mail thread to try to convince each other
neither to discuss technicality of the different proposals on the table 
or different/new one:
if you want to discuss them please start a different thread for them.

An appropriate mail subject would also help people to follow better the 
different discussions.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 14 Jan 2011 14:14:28 -0800

> some ISPs indicate that network bandwidth doubles every 9 months.

Maybe on the backbone, but not last mile bandwidth.

 - Maciej

---

From: Joel Martin <[email-masked]>
Date: Sun, 16 Jan 2011 01:02:38 -0600

I believe the history of "last mile" since 1979 has shown a doubling every 2
years:

http://www.cabletechtalk.com/tech-discussions/2008/08/14/broadband-speed-and-moores-law-a-response-to-robb-topolski/

I think the real point is that adding a few percent to the size of
WebSockets traffic will quickly be addressed by the natural increase in
bandwidth (both backbone and last-mile). But security issues don't easily
fix themselves with time. It seems to me the WebSockets priorities should be
security, then ease of implementation, then latency, with bandwidth at the
end of the list.

Joel Martin

On Fri, Jan 14, 2011 at 4:14 PM, Maciej Stachowiak <[email-masked]> wrote:

> >> Using more bandwidth to save CPU strikes me as a poor tradeoff. CPU
> speeds increase at a faster rate than network bandwidth, or for that matter
> memory bandwidth.
> >

---

From: Joel Martin <[email-masked]>
Date: Sun, 16 Jan 2011 13:37:16 -0600

For the masking straw poll my preference is strongly for #1.

However, I think enough interest is being expressed in alternate encodings
that another straw poll may be in order after the masking poll closes. I.e.
1) base64  2) 7-bit/8-bit  3) whichever masking option "wins". The con
against 1 and 2 seems to be bandwidth which to me doesn't seem like an
compelling concern in this case.

Joel Martin

On 1/16/11 8:02 AM, Joel Martin wrote:

> I believe the history of "last mile" since 1979 has shown a doubling every
> 2 years:
>
>
>

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 16 Jan 2011 12:03:13 -0800

On Jan 15, 2011, at 11:02 PM, Joel Martin wrote:

> I believe the history of "last mile" since 1979 has shown a doubling every 2 years:
> 

And computational power doubles about every 18 months,

> 
> I think the real point is that adding a few percent to the size of WebSockets traffic will quickly be addressed by the natural increase in bandwidth (both backbone and last-mile). But security issues don't easily fix themselves with time. It seems to me the WebSockets priorities should be security, then ease of implementation, then latency, with bandwidth at the end of the list.

If security is really the top priority, and in particular if it's a higher priority than computational complexity, then a making scheme that produces data indistinguishable from random is the best choice. As I understand it, the base64 proposal is based on the premise that AES-CTR or HMAC are too expensive in CPU time to be worth the security benefit.

Regards,
Maciej

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 17 Jan 2011 01:49:21 +0100

* Maciej Stachowiak wrote:
>If security is really the top priority, and in particular if it's a
>higher priority than computational complexity, then a making scheme that
>produces data indistinguishable from random is the best choice.

Limiting an attacker's ability to confuse intermediaries is just one
aspect of security; limiting confusion about the protocol's security
properties is another. We can take for granted that if we were to use
AES in the protocol that some people will make incorrect assumptions
about the security properties that provides; we've seen people on this
list who've closely followed the discussions do that, for instance.
AES may very well be the worst option as far as overall security goes.
-- 
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: Gabriel Montenegro <[email-masked]>
Date: Tue, 18 Jan 2011 17:41:48 +0000

Hi Sal,

> 1. a fixed mask carried entirely in the packet.

+1. Session-less is good. This is cheap and allows wide deployment. 

> In the case you have more then one, please put the choices in a

As others have said, I won't cut my wrists over #2 or #3 (in that order of preference), but see no real need to go there.

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 18 Jan 2011 19:12:48 +0100

This poll ends today (January 18th),
if you haven't cast a vote, please do it now!

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: "Joonas Lehtolahti" <[email-masked]>
Date: Tue, 18 Jan 2011 20:33:27 +0200

> e.g. AES-CTR or HMAC-SHA).

While I still personally would prefer no masking at all, of those three
options my vote goes to number 1. The most important point for me would be
just getting WebSocket out to be usable in a real world applications, so
if other options are what's required to get this protocol into state where
it will be again deployed in web browsers, then I will not try to stop you.

- Joonas

PS. Sorry Sal, looks like the mailing list address dropped out of the  
original message.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 18 Jan 2011 11:15:04 -0800

I am not entirely sure what people mean by a fixed mask. For it to be worth
while, the mask would have to change every frame so that the attacker
doesn't have advanced knowledge of the mask.

So, for me to live with it, we have to have something that changes every
frame if it's worth doing at all.

As for whether we use XOR(SHA(c-nonce, s-nonce, rand)) or AES, I could live
with either. Frankly I don't think that either are prohibitively expensive,
especially compared to something that would cause us to significantly
increase bandwidth requirements (base64).

-Ian

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 18 Jan 2011 19:31:45 +0000

I am not entirely sure what people mean by a fixed mask. For it to be worth while, the mask would have to change every frame so that the attacker doesn't have advanced knowledge of the mask.

So, for me to live with it, we have to have something that changes every frame if it's worth doing at all.

[gab] Agree. My understanding is that this is option #1, a per-frame key.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 18 Jan 2011 20:34:14 +0100

Hi Ian,

> doesn't have advanced knowledge of the mask.

That was point "1.5" which was not kept in the poll.

> increase bandwidth requirements (base64).

It depends on how you see it. Speaking as someone who develop intermediaries,
having a 3 GHz CPU not being able to process 1 Gbps of traffic is a big
concern, considering that the same machine has no issue at 10 Gbps of HTTP.

If we have to make the trade-off, I'd say that "base128" is "only" 14%
network overhead for frames above around a hundred bytes, while AES-CTR
is a >1000% CPU overhead for all frame sizes. XOR(HMAC/SHA) is even a
much higher overhead for small frames which should be our main target.

That's something to keep in mind. We could try to think how much time it
will take for network speeds to increase by our overhead and how much time
it will take for CPU speeds to increase by our overhead. In the first case
it's just a matter of few months, maybe only one, in the second case it's
a matter of several years.

I'm not much for causing network overheads but I'm comparing two costs
if we have to choose an alternative.

The simple XOR has none of them though.

Regards,
Willy

---

From: John Tamplin <[email-masked]>
Date: Tue, 18 Jan 2011 14:37:25 -0500

> frame if it's worth doing at all.

I believe #1 means simply a random per-frame mask which does not depend on
any information outside the frame to interpret it, as opposed to requiring
client-nonce or server-nonce (which means any interpretation of the framing
requires keeping extra state).

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 18 Jan 2011 12:28:11 -0800

On Tue, Jan 18, 2011 at 11:37 AM, John Tamplin <[email-masked]> wrote:

>> I am not entirely sure what people mean by a fixed mask. For it to be
>> worth while, the mask would have to change every frame so that the attacker
In that case, I can live with all three. I have a preference for AES as it's
easier to reason about its security properties and I don't really think that
the "export restriction" barriers are that big a deal, indeed SSL seems to
be deployed all over the place.

-Ian

---

From: Senthilkumar Peelikkampatti <[email-masked]>
Date: Tue, 18 Jan 2011 16:29:35 -0600

I prefer option 1, though I wish to have no masking, anyway it makes better
trade off for me.

Other than having WS and WSS, we can split WS into masked and unmasked
variant,

1) WSS for secured connection (wss://)
2) WSMASKED for masked  (wsmask://)
3) WS for  (ws://) no masking

When we move on to perfect defect free intermediaries we can stick to WS,
this gives the application developer  option to choose based on what kind of
intermediary they have.

When we talk to about Browser ----> Intermediary ------> http server
--------> Websocket server, architecture choice is with app developer for
everything but browser. If we provide that option, it would definitely help
next million users chat/websocket app developer option to choose.

Senthilkumar Peelikkampatti,
https://github.com/sendtopms/Erlwebsockserver.

-- 
Regards,
Senthilkumar Peelikkampatti,
http://pmsenthilkumar.blogspot.com/

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 18 Jan 2011 14:31:48 -0800

That depends. A ton of processors are adding in new instructions (and
hardware support) for AES. A list of Intel processors, as an example:
http://ark.intel.com/MySearch.aspx?AESTech=true

On Tue, Jan 18, 2011 at 11:34 AM, Willy Tarreau <[email-masked]> wrote:

> worth

---

From: Senthilkumar Peelikkampatti <[email-masked]>
Date: Tue, 18 Jan 2011 16:58:41 -0600

There are AMDs and upcoming ARM based systems going to invade datacenters.
We can't count on this list perhaps 5 years down the line we would get
hardware accelerated crypto.

2011/1/18 Ian Fette (イアンフェッティ) <[email-masked]>

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 19 Jan 2011 00:27:01 +0000

> if you haven't cast a vote, please do it now!

Of the three options on the table, I prefer #1 or something more like
it than the other two options.

I don't see the point of half-baked "security" that is not a secure
channel, just encryption to randomise the data.  I think people would
treat the presence of encryption in WebSocket as though that makes it
a secure channel, when it is only weakly so.

And I dislike the cost of repeated AES or SHA just to make it still an
insecure channel; mainly the CPU cost.  As well as the cost to
intermediaries that do any more than forwarding TCP blind, and
possible user-visible latency and network costs following from that.

When you want proper security, use TLS (wss:), and when you don't (or
you know it's over a VPN etc.), use only the simplest thing necessary
to prevent browser script attacks.  Especially when there's a cost.

However, I would not necessarily object if someone finds (or designs)
a lower-overhead, strong random XOR sequence (with LF escaping perhaps)
that is strong against future browser script attacks but doesn't cost
much to handle at low-power intermediaries and endpoints, presumably
by them having access to more hidden state than attackers.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 19 Jan 2011 00:53:02 +0000

> >produces data indistinguishable from random is the best choice.

No, we have shown that is false in this case.

Don't confuse different types of security.

In this case, the "security" being talked about is _not_ for making
secure communications!

(If you want that, you should use the wss: scheme, which uses TLS and
everyone seems to be fine with that.)

In this case, the "security" is about preventing particular kinds of
browser-based Javascript attacks on intermediaries.

For that, a scheme which produces data indistinguishable from random
has been shown _not_ to be the best choice - even if security has
absolute priority over computational complexity.

It has been shown, with thought experiments and some knowledge of real
current proxies, how it might be exploitable, now or in future.  It's
not a very realistic attack, but not totally implausible either.  Even
if it were, it is good practice to try to avoid plausible holes,
instead of considering only specific attacks known at design time.

That is completely different from the type of security provided by
SSL/TLS, for which indistinguishability from random is one of the
desirable factors (but not enough by itself).

> AES may very well be the worst option as far as overall security goes.

I agree.  I predict if AES is used prominently and the traffic "looks
encrypted", many people will mistakenly treat ws: as a secure channel,
or perhaps even not by mistake but just because it's easy to use and
"good enough" against low-grade attackers.

I prefer that TLS is used where security is considered worth the
effort.  It's not that expensive if you were planning on encrypting
anyway, and wss: should be no more difficult to set up than https:.

-- Jamie

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 18 Jan 2011 17:57:19 -0800

I hope this is obvious, but I did not intend that list to be complete,
merely to indicate a trend in newer hardware.

-Ian

2011/1/18 Senthilkumar Peelikkampatti <[email-masked]

---

From: "Alakkad, Achuth (GE Healthcare)" <[email-masked]>
Date: Fri, 21 Jan 2011 14:56:18 +0530

If masking is a means for allowing the packet to pass through
intermediaries without any trouble, then I am not sure why we are
concerned about the data security.
If anyone is keen on content security he should use wss rather than ws.
Am not sure why we are concerned about which algorithm to use for
masking as its process intensive, rather will use a very simple
universal static mask to bypass intermediaries.
 
ws is similar to http, any one can sniff data from network.

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Senthilkumar Peelikkampatti
Sent: Wednesday, January 19, 2011 4:00 AM
To: Salvatore Loreto
Cc: Joe Hildebrand; [email-masked]
Subject: Re: [hybi] Straw-poll on Masking options

I prefer option 1, though I wish to have no masking, anyway it makes
better trade off for me.

When we move on to perfect defect free intermediaries we can stick to
WS, this gives the application developer  option to choose based on what
kind of intermediary they have. 

When we talk to about Browser ----> Intermediary ------> http server
--------> Websocket server, architecture choice is with app developer
for everything but browser. If we provide that option, it would
definitely help next million users chat/websocket app developer option
to choose. 

On Wed, Jan 12, 2011 at 2:00 PM, Salvatore Loreto
<[email-masked]> wrote:

	Hi all,

	Masking from the client to the server
	has reached strong consensus within this wg as a mechanism to
reduce security risks.
	
	However there is disagreement on the actual method for masking.
	The technical differences, pro and cons, advantages and
disadvantages,
	as well as the legal implications of each method have already
been deeply discussed.
	
	In order to settle the question of masking and find a way
forward that has a wide acceptance,
	Joe and I, as HyBi chairs, want to check where the consensus is
	on the following relevant options that have been discussed (and
summarized at
	some point in the mailing list by Eric Rescorla)

	2. A longish repeated mask computed from the packet. For
concreteness,
	  suppose HMAC-SHA1(<uuid>, <server-conn-key> ||
<client-conn-key> || <packet-key>), but
	  obviously there's flexibility here.
	
	3. A fully generated mask (if so specify also what you would
like to use e.g. AES-CTR or HMAC-SHA).

	Please indicate your preference(s) or the one can meet your bar
for "I could live with that";
	In the case you have more then one, please put the choices in a
preference order.

	cheers
	/Sal
	
	-- 
	Salvatore Loreto
	www.sloreto.com

---

From: Adam Barth <[email-masked]>
Date: Fri, 21 Jan 2011 02:26:22 -0800

Use a universal static mask does not prevent the attacker from
choosing the bytes on the wire because if the mask is universally
known, the attack can simply pick a plaintext that becomes his desired
bytes when masked.

Adam

On Fri, Jan 21, 2011 at 1:26 AM, Alakkad, Achuth (GE Healthcare)
<[email-masked]> wrote:
> If masking is a means for allowing the packet to pass through intermediaries
> without any trouble, then I am not sure why we are concerned about the data
> security.
> If anyone is keen on content security he should use wss rather than ws. Am
> not sure why we are concerned about which algorithm to use for masking as
> its process intensive, rather will use a very simple universal static mask
> to bypass intermediaries.
>

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 23 Jan 2011 19:29:20 +0000

Alakkad, Achuth (GE Healthcare) wrote:
>    If anyone is keen on content security he should use wss rather than
>    ws. Am not sure why we are concerned about which algorithm to use for

The discussion is talking about different kinds of security, using the
word "security" for all of them, which appears to have confused several people.

You are talking about the ability to sniff data, for which wss: is effective.

Other uses of "securiry" in this discussion are the ability to (a)
attack servers using scripts running in browsers, and (b) poison
intermediary caches using scripts running in browsers collaborating
with the attacker's server.  wss: doesn't help with those.

It's possible the type of masking makes a difference to attacks, but
there is no consensus about it.  There are no actual tests indicating
one clearly superior approach, but there are tests showing that
various attacks can be done, or in some cases are plausible but have
not been done.  The choice of algorithm to use is mostly theoretical,
but none of the theories is watertight.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 23 Jan 2011 19:39:30 +0000

Senthilkumar Peelikkampatti wrote:
>    WS, this gives the application developer  option to choose based on
>    what kind of intermediary they have.

The app developer doesn't know what kind of intermediaries there are.

>    for everything but browser.

Senthilkumar, the above is incorrect.

The app developer does not control intermediaries on the client's own
machine (there are such products), on the client's network (e.g. their
cache and/or corporate/school filtering), at their ISP(s), and
government-level filter if there is one (great firewall of...)

-- Jamie