Subject: [hybi] Straw Poll: is Upgrade with client->sever XOR mask acceptable?

From: "Pat McManus @Mozilla" <[email-masked]>
Date: Wed, 22 Dec 2010 12:25:52 -0500

Hi all,

Like everyone else I am looking for a way forward that gives us a good
protocol with wide acceptance soon. It doesn't have to be the best
protocol and if "wide acceptance" is our goal it is unlikely a wide
group would agree on the definition of "best" anyhow. It should go
without saying that wide != universal.

With that in mind I want to ask everyone if they think an approach based
on Get+Upgrade containing mandatory client->server XOR masking meets the
bar of an acceptable and good web sockets protocol.

Maybe you think that a CONNECT based approach is marginally better (I
personally do, btw), or an all TLS-NPN approach is best, or using a
different port and abandoning HTTP semantics is the best way to go.. but
that's not my question here - all of those things have pretty severe
objections lodged against them that weigh them down. We already know
unofficially from just reading the archives that there isn't consensus
around their suitability at this time and I don't see a lot of minds
being changed as a result of all the email.

So my question is does the upgrade-with-unidirectional-xor-mask meet
your bar for "I could live with that". Saying yes doesn't mean that you
will be called a hypocrite for supporting something else with a higher
preference. 

I have just reread the last month's worth of archives and I am aware of
one point of view that thinks the mask is just too expensive to be
worthwhile and I was (surprisingly to me) unable to find any other
fundamental objections although several folks did note there are costs
involved. I am not claiming I found a lot of explicit support either,
just that the path seems to clear to ask this question.

Let me make the pitch:

* The approach is HTTP spec friendly and routable.
* It is intermediary friendly in the sense that it is a plaintext
equivalent and interacts with HTTP upgrade in the expected manner.
Obviously changes need to be made in the way Upgrade envisioned.
* It acknowledges that any known handshake might still have issues with
intermediaries inspecting the data path and being exposed to
poison/spoofing attacks but it secures the data path against that with a
relatively low cost masking.
* it does not have dependencies on other specs, deployments, etc
* it does not have potential issues with regulatory compliance whether
those issues are externally (licenses, etc..) or internally (legal
review) imposed.
* It accomplishes this at reasonable cost 
  + masking is unidirectional and favors the server end. I've worked on
servers in the past and right now I'm working on a browser and I really
do believe that is the right trade off. A browser is much more
interested in latency than in overall load scaling, while a server has
real concerns about the latter. making sendfile() useless to the browser
is no big deal - it doesn't help with latency when compared to IP time
scales and the client is less likely to have the kind of data that would
be zero copied anyhow.
  + XOR in place for something that is already sitting in memory is a
trivial cost in terms of CPU and essentially a zero cost in terms of
memory, so it is suitable for low level embedded clients.

I want to acknowledge that I think the biggest downside here is actually
the expanded framing cost of including the key on every frame -
especially in the case of mobile agents sending frames using the 0-125
byte payloads in order to save transmission power. This will be a
significant tax on that use case, but given the overall situation, the
benefits of this proposal, and the relative nicheness of that
requirement I can swallow that tax and live with it in good conscience.

The other thing worth noting is that that I went the XOR route instead
of AES here. We've had a number of objections to AES based on
compliance, bundling, and to a lesser degree performance. The
explanation on list for favoring AES deals with an attacker being able
to control the relationship between bytes in the data stream but not
their actual values - no one has suggested a vector by which this is a
problem for our non-cryptographic goal. But if your objection to
get-upgrade-with-unidirectional-xor is that it requires AES to meet a
level of "that's acceptable to me" (not just better), please do state
that explicitly and as a favor to me help explain what the exposure is.

-Patrick

(I haven't mentioned hello - greg points out that it has value
independent of the handshake/mask and I therefore simply want to treat
it independently.)

-- 
http://www.getfirefox.com/

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 22 Dec 2010 18:43:14 +0100

On 22 December 2010 18:25, Pat McManus @Mozilla <[email-masked]> wrote:
> your bar for "I could live with that".

I could live with that.

> significant tax on that use case,

I think making it optional for non-browser clients could help with
reducing that taxation burden.
But I could live with it being non-optional.

cheers

---

From: Brian McKelvey <[email-masked]>
Date: Wed, 22 Dec 2010 10:11:29 -0800

+1

Sent from my iPhone

On Dec 22, 2010, at 9:25 AM, "Pat McManus @Mozilla" <[email-masked]> wrote:

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

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 22 Dec 2010 18:16:31 +0000

+1

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian McKelvey
> Sent: 22 December, 2010 10:11
> To: Pat McManus @Mozilla
> Cc: hybi
> Subject: Re: [hybi] Straw Poll: is Upgrade with client->sever XOR mask
> acceptable?
> 
> +1
> 
> Sent from my iPhone
> 
> > With that in mind I want to ask everyone if they think an approach
> > based on Get+Upgrade containing mandatory client->server XOR masking
> > meets the bar of an acceptable and good web sockets protocol.
> >
> > different port and abandoning HTTP semantics is the best way to go..
> > but that's not my question here - all of those things have pretty
> > severe objections lodged against them that weigh them down. We already
> > know unofficially from just reading the archives that there isn't
> > consensus around their suitability at this time and I don't see a lot
> > of minds being changed as a result of all the email.
> >
> > your bar for "I could live with that". Saying yes doesn't mean that
> > you will be called a hypocrite for supporting something else with a
> > higher preference.
> >
> > I have just reread the last month's worth of archives and I am aware
> > of one point of view that thinks the mask is just too expensive to be
> > * It acknowledges that any known handshake might still have issues
> > with intermediaries inspecting the data path and being exposed to
> > poison/spoofing attacks but it secures the data path against that with
> > a relatively low cost masking.
> > * It accomplishes this at reasonable cost  + masking is unidirectional
> > and favors the server end. I've worked on servers in the past and
> > right now I'm working on a browser and I really do believe that is the
> > right trade off. A browser is much more interested in latency than in
> > overall load scaling, while a server has real concerns about the
> > latter. making sendfile() useless to the browser is no big deal - it
> > doesn't help with latency when compared to IP time scales and the
> > client is less likely to have the kind of data that would be zero
> > copied anyhow.
> > I want to acknowledge that I think the biggest downside here is
> > actually the expanded framing cost of including the key on every frame
> > - especially in the case of mobile agents sending frames using the
> > 0-125 byte payloads in order to save transmission power. This will be
> > a significant tax on that use case, but given the overall situation,
> > the benefits of this proposal, and the relative nicheness of that

---

From: Roberto Peon <[email-masked]>
Date: Wed, 22 Dec 2010 10:53:52 -0800

+1 yes please.

Note that the most likely attack vector (imho) against the xor mask is to
send a large payload and thus have the ability to get your plaintext through
with enough bytes of payload.
(e.g.
for i in 0-2^masksize:
  message.append(mask(plaintext, i)))

-=R

---

From: John Tamplin <[email-masked]>
Date: Wed, 22 Dec 2010 14:07:47 -0500

+1 to GET+Upgrade with client->server XOR masking from me.

>   message.append(mask(plaintext, i)))

The same attack would work for AES-CTR as well.

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

---

From: Patrick McManus <[email-masked]>
Date: Wed, 22 Dec 2010 14:12:04 -0500

On Wed, 2010-12-22 at 11:01 -0800, Adam Barth wrote:

> I didn't see a detailed proposal in your message, but I'm assuming you
> mean generating a new per-frame nonce and then XORing the rest of the
> frame with information derived from the nonce with the goal of making
> it difficult for the attacker to control the bytes sent on the wire.

broadly, yes!

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 22 Dec 2010 20:14:39 +0100

I want to thank a lot Patrick for the initiative of this straw poll.

as chair I have to say that I share the same Patrick's feeling:
after a tons of mails I haven't seen a lot of mind being changed!

having said that, I think it is really time to check
"/where we can put the bar of an acceptable and good web sockets protocol/",
or if you prefer it expressed in an IETF style
*where/on which proposal we can reach the rough consensus*

In the sake of making progress,
I would change the poll, generalizing it on an approach based on
"GET+Upgrade containing mandatory client-server masking"

let the decision of what kind of mask to use for a next step/poll.
(as well as the hello/Greg point)

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 22 Dec 2010 19:29:09 +0000

Just to be clear.

You're changing Patricks proposal from:

"upgrade-with-unidirectional-xor-mask"

(where "unidirectional means "client to server")

To:

"upgrade-with-unidirectional -mask"

The only change is the type of mask (which we can decide on after this). Sounds good.

Thanks,

Gabriel

From: [email-masked] [mailto:[email-masked]] On Behalf Of Salvatore Loreto
Sent: 22 December, 2010 11:15
To: [email-masked]; Patrick McManus
Subject: Re: [hybi] Straw Poll: is Upgrade with client->sever XOR mask acceptable?

having said that, I think it is really time to check
"where we can put the bar of an acceptable and good web sockets protocol",
or if you prefer it expressed in an IETF style
*where/on which proposal we can reach the rough consensus*

cheers
/Sal

--

Salvatore Loreto

www.sloreto.com<http://www.sloreto.com>

Hi all,

preference.

Let me make the pitch:

review) imposed.

be zero copied anyhow.

-Patrick

it independently.)

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 22 Dec 2010 20:29:21 +0100

Hi Pat,

I too would like to see if we can go down that route.
I think we should keep in mind that a short time after the protocol
is widely adopted, the masking will become useless because broken
intermediaries we're afraid of will have been fixed because their
incompatibility will have been noticed. So we should probably think
the thing with a version 1.1 in mind where we can later indicate the
other side that there is no masking, without having to perform
important changes. That will make it easier to save the bytes you
need on mobile networks.

So +1 for me.

Thanks,
Willy

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 22 Dec 2010 20:39:25 +0100

On 12/22/10 8:29 PM, Gabriel Montenegro wrote:
>
> Just to be clear.
>
> You’re changing Patricks proposal from:
>
> “upgrade-with-unidirectional-xor-mask”
>
> (where “unidirectional means “client to server”)
>
> To:
>
> “upgrade-with-unidirectional -mask”
>
right!
thanks for the clarification

/Sal

> Thanks,
>
> Gabriel
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Salvatore Loreto
> *Sent:* 22 December, 2010 11:15
> *To:* [email-masked]; Patrick McManus
> *Subject:* Re: [hybi] Straw Poll: is Upgrade with client->sever XOR 
> mask acceptable?
>
> www.sloreto.com  <http://www.sloreto.com>
>
>
>
>
>
>

-- 
Salvatore Loreto
www.sloreto.com

---

From: John Tamplin <[email-masked]>
Date: Wed, 22 Dec 2010 14:43:16 -0500

> important changes. That will make it easier to save the bytes you

I would worry about an optional mask leading to lazy implementors not
bothering to implement it, which would leave us in the state we are trying
to avoid

However, the implementations we really care about are web browsers, since
they could be so easily used by third parties to mount an attack, so maybe
it isn't a problem to say that clients can optionally implement it (and
*strongly* encouraging browser clients to do so) and requiring servers to be
able to accept it.

---

From: John Tamplin <[email-masked]>
Date: Wed, 22 Dec 2010 14:43:16 -0500

---

From: Scott Ferguson <[email-masked]>
Date: Wed, 22 Dec 2010 11:54:27 -0800

+1

Assuming it's specified as a required extension so non-hijackable 
clients can use the unmasked framing like the server does. (In other 
words, I'd like to see Willy's "1.1" built into the base spec.)

-- Scott

---

From: John Tamplin <[email-masked]>
Date: Wed, 22 Dec 2010 15:05:52 -0500

On Wed, Dec 22, 2010 at 2:54 PM, Scott Ferguson <[email-masked]> wrote:

> Assuming it's specified as a required extension so non-hijackable clients
> can use the unmasked framing like the server does. (In other words, I'd like
> to see Willy's "1.1" built into the base spec.)
>

If we go that route, personally I would prefer to see the extension be to
remove the masking -- that way simple implementations can just skip
extension support entirely if they want.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Dec 2010 12:11:54 -0800

I'm really not comfortable with omitting the masking at all. I don't see
much benefit and significant risks
from mistakes.

-Ekr

---

From: Adam Barth <[email-masked]>
Date: Wed, 22 Dec 2010 12:13:02 -0800

I could not live with optional masking.

Adam

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 22 Dec 2010 21:20:06 +0100

> bothering to implement it, which would leave us in the state we are trying

Note that I'm not talking about "optional masking", but just to see how we
can *later* remove it. That might mean making it easy to support masked and
unmasked frames in the context of a spec update (eg: have a fixed-length
nonce that can easily be skipped without changing the frame format if some
HTTP header or indication in a hello frame says no masking will be used).
That's just what I'm suggesting. But for now, let's keep it to stay on the
safe side and satisfy everyone.

Thanks,
Willy

---

From: John Tamplin <[email-masked]>
Date: Wed, 22 Dec 2010 15:24:36 -0500

> safe side and satisfy everyone.

So I suggest that if, in the future, we determine the masking is no longer
useful, we can create an extension (say, noclientmask), which if accepted by
the server means the client does not perform masking.

Until then, every client and server have to implement masking.

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 22 Dec 2010 21:29:25 +0100

before start to discuss if masking has to be a MUST or a SHOULD in the spec

I would like people be focused on the right question of the pool as 
raised by Patrick
and generalized by myself.
In this way the chairs can make an opinion of what kind (if any) of 
consensus we have.

The question is:

/do you think that an approach based on
"GET+Upgrade containing mandatory client-server masking"
(where "unidirectional" means "client to server")
meets the bar of an acceptable and good web socket protocol ?
/

cheers
/Sal

On 12/22/10 9:13 PM, Adam Barth wrote:
> On Wed, Dec 22, 2010 at 12:11 PM, Eric Rescorla<[email-masked]>  wrote:
>> On Wed, Dec 22, 2010 at 12:05 PM, John Tamplin<[email-masked]>  wrote:
>>> On Wed, Dec 22, 2010 at 2:54 PM, Scott Ferguson<[email-masked]>  wrote:

-- 
Salvatore Loreto
www.sloreto.com

---

From: Scott Ferguson <[email-masked]>
Date: Wed, 22 Dec 2010 12:30:10 -0800

John Tamplin wrote:
> On Wed, Dec 22, 2010 at 3:20 PM, Willy Tarreau <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> So I suggest that if, in the future, we determine the masking is no 
> longer useful, we can create an extension (say, noclientmask), which 
> if accepted by the server means the client does not perform masking.
>

Right. That works just as well.

-- Scott

> ------------------------------------------------------------------------
>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 22 Dec 2010 21:54:39 +0100

> Until then, every client and server have to implement masking.

Fine for me.

Willy

---

From: Paul Colomiets <[email-masked]>
Date: Thu, 23 Dec 2010 00:07:34 +0200

I'm saying Yes for GET+Upgrade with client->server XOR masking

Note that the most likely attack vector (imho) against the xor mask is to send a large payload and thus have the ability to get your plaintext through with enough bytes of payload.

(e.g.

for i in 0-2^masksize:

Well, it's impractical for 128bit AES key, an even for something like 4 or 6 bytes of simply random masking

--
Paul

---

From: John Tamplin <[email-masked]>
Date: Wed, 22 Dec 2010 17:12:28 -0500

> 6 bytes of simply random masking

Right, I think the practicality of that attack is entirely dependent on the
size of the key space, and unrelated to whether XOR or AES is being used.

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 22 Dec 2010 22:17:20 +0000

Adam and Eric,

Folks are saying that they're fine with mandatory masking. Does this mean you're ok with the strawpoll?

Gabriel

> Adam Barth
> Sent: 22 December, 2010 12:13
> To: Eric Rescorla
> Cc: hybi
> > I'm really not comfortable with omitting the masking at all. I don't
> > see much benefit and significant risks from mistakes.
> >
> > -Ekr
> >
> >> If we go that route, personally I would prefer to see the extension
> >> be to remove the masking -- that way simple implementations can just
> >> skip extension support entirely if they want.
> >>
> >> --
> >> John A. Tamplin

---

From: Adam Barth <[email-masked]>
Date: Wed, 22 Dec 2010 14:35:25 -0800

> Folks are saying that they're fine with mandatory masking. Does this mean you're ok with the strawpoll?

I responded earlier, but my message doesn't seem to be showing up in
the hybi archives.  Here's what I wrote:

> without saying that wide != universal.

Thanks Pat.  This is very helpful.

> will be called a hypocrite for supporting something else with a higher

If done correctly, I could live with that.  In particular:

1) We should mask as much of the attacker-controlled portions of the
initial message as we can.  In particular, we should mask everything
the attacker controls with the possible exception of the Host header /
request-line.

2) We should use something to expand the nonce into a larger pad for
XORing with the frame.  For example, we should use SHA-1 to expand the
nonce to a 20 byte.  (Ideally, we would use AES-128-CTR to expand the
nonce to an arbitrary length pad.)  This will help with the issue
Roberto Peon raises w.r.t. brute-forcing the pad.

3) The pad should contain information initially received from the
server to prevent the attacker from using POST to attack WebSocket
servers (as Maciej often reminds us to worry about).

I have slight reservations about the fact that the server-to-client
messages aren't masked.  I'll think some more about whether that's
problematic.

Adam

---

From: John Tamplin <[email-masked]>
Date: Wed, 22 Dec 2010 17:49:40 -0500

> the attacker controls with the possible exception of the Host header /

Does that include Sec-WebSocket-Protocol, which is attacker-controlled?  Or
is restricting the character set that is allowed sufficent?

> Roberto Peon raises w.r.t. brute-forcing the pad.

20 bytes per frame is a lot, and it doesn't really seem necessary.  If the
attack text needed to influence intermediaries is even 20 bytes, which seems
insufficient, then with a 4-byte pad the payload required to brute-force the
pad would be 80G.  Given current APIs available to the attacker in browsers,
it seems completely impractical to mount this attack.

If you are still worried, then a 6-byte random value should provide more
than enough key space to render this attack infeasible.

> servers (as Maciej often reminds us to worry about).

Something like this (which would also reduce correlation between masked
bytes if the nonce is a different length than the per-frame key)?

for (int i = 0; i < payload.length; ++i) {
  output[i] = payload[i] ^ perFrameKey[i % perFrameKey.length] ^
combinedClientServerNonce[i % combinedClientServerNonce.length];
}

> messages aren't masked.  I'll think some more about whether that's

Since we already assume the attacker controls the server, he can always
generate whatever value he wants on the wire.  He could probably do it
without WebSockets, simply issuing a GET (script or img tags would avoid
origin restrictions) and responding with whatever he likes.

---

From: Adam Barth <[email-masked]>
Date: Wed, 22 Dec 2010 15:00:17 -0800

> is restricting the character set that is allowed sufficent?

I think restricting it to space-separated tokens is probably fine.

> 20 bytes per frame is a lot, and it doesn't really seem necessary.

20 bytes is just the output of SHA-1.

> If the attack text needed to influence intermediaries is even 20 bytes, which seems
> pad would be 80G.

That's a question of the input size.

> Given current APIs available to the attacker in browsers,

I'd just do:

perFrameKey = SHA-1("some constant string" || perFrameNonce || serverNonce);
for (int i = 0; i < payload.length; ++i) {
  output[i] = payload[i] ^ perFrameKey[i % 20];
}

> origin restrictions) and responding with whatever he likes.

Right, my concern is in threat models where the attacker doesn't
control the server.  As I said, I don't have a concrete issue, just a
slight reservation that I'd like to think more about (but certainly
not block progress because of).

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Dec 2010 23:27:22 -0500

+1

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 22 Dec 2010 20:38:11 -0800

>  output[i] = payload[i] ^ perFrameKey[i % 20];

I think it's also helpful to have an initial client-generated nonce folder into this, in case an attacker can affect the client's payload but not the request header. (I will think about the proposal further time permittion; I'm on vacation now so I have not been able to read the thread thoroughly.

Regards,
Maciej

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 23 Dec 2010 09:16:01 +0100 (CET)

On Wed, 22 Dec 2010, Pat McManus @Mozilla wrote:

> With that in mind I want to ask everyone if they think an approach based on 
> Get+Upgrade containing mandatory client->server XOR masking meets the bar of 
> an acceptable and good web sockets protocol.

+1 on this and the more generic version of it as put by Salvatore Loreto.

-- 

  / daniel.haxx.se

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 23 Dec 2010 09:06:09 -0800

I still worry that this is going to lead to deployment problems in terms of
schools/libraries/etc that have monitoring software in place that this will
break. On the plus side it's relatively straight-forward for them to un-mask
the content, and the fact that it's only one way also helps a lot. I think
this solution is far from ideal, but at the end of the day I can live with
it.

I'm going on vacation in a few hours, but if the current trend of general
consensus continues on this thread, I will gladly write up a -04 based on
this suggestion when I return the first week of January.

-Ian

---

From: John Tamplin <[email-masked]>
Date: Thu, 23 Dec 2010 12:24:31 -0500

> this solution is far from ideal, but at the end of the day I can live with

It seems to me that it will be a lot easier for them then TLS+NPN with the
NULL cipher (unless they are just doing something that looks for certain
strings) since they probably don't see that at all now and would have to
watch the TLS negotiation.

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 23 Dec 2010 20:46:22 +0100

Hi there,

so far there seems to be a general support for /"GET+Upgrade containing 
mandatory client-server masking"
/with few people that have expressed reservations depending on how the 
masking is implemented
and only one complaining about the proposal.

Considering that several people are on holidays,
Joe and I, as chairs, will let run this Poll until January 7th.

In the meanwhile we want encourage people to focus the discussion on 
what kind of masking (and what optimization)
would make this approach secure (/sending out detailed proposals or 
commenting the one sent by others)/

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 23 Dec 2010 22:41:49 -0700

After reviewing this thread, here are my comments:

- I am happy with client -> server masking.

- I can live with GET+Upgrade as the handshake, so long as the masking is strong enough.

- I think GET+Upgrade followed by a fake CONNECT, as proposed by David Cridland, is superior to vanilla GET+Upgrade, if there are no objections  to it. I believe his proposal is fully HTTP compliant, and does not add round trips. I would appreciate if we could check whether there are objections to that approach, from people who accept GET+Upgrade. <http://tools.ietf.org/html/draft-cridland-hybi-upgrade-connect-00>. (Note, I do not necessarily mean adopt that whole proposal verbatim, just the extra CONNECT message as the first client->server packet after accepting 101. Server send does not have to wait on this fake CONNECT.)

- I can live with correct routing information in the handshake, especially if we adopt David Cridland's fake-CONNECT-as-client-hello approach.

I have opinions on the details of the masking, but I will comment on those in the masking thread.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 23 Dec 2010 22:49:09 -0700

On Dec 22, 2010, at 12:43 PM, John Tamplin wrote:

> I would worry about an optional mask leading to lazy implementors not bothering to implement it, which would leave us in the state we are trying to avoid
> 
> However, the implementations we really care about are web browsers, since they could be so easily used by third parties to mount an attack, so maybe it isn't a problem to say that clients can optionally implement it (and *strongly* encouraging browser clients to do so) and requiring servers to be able to accept it.

Masking should not be optional. If we use GET+Upgrade as the handshake, almost all of our security against cross-protocol attacks will rest on masking. If there is a way to turn it off, then tricking clients and servers into turning it off becomes an extremely powerful attack. Even if that is possible only in the face of bugs, it's still very dangerous. Therefore I would recommend against this. If we get evidence that this is needed in the future, we can revisit the issue.

Regards,
Maciej

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 24 Dec 2010 15:26:15 +0900

+1. Let's make progress.    Regards,   Martin.

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

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Fri, 24 Dec 2010 13:16:46 -0800

I agree with Maciej below.

On Thu, Dec 23, 2010 at 9:41 PM, Maciej Stachowiak <[email-masked]> wrote:

> - I think GET+Upgrade followed by a fake CONNECT, as proposed by David
> Cridland, is superior to vanilla GET+Upgrade, if there are no objections  to
> it. I believe his proposal is fully HTTP compliant, and does not add round
> trips. I would appreciate if we could check whether there are objections to
> that approach, from people who accept GET+Upgrade. <
> http://tools.ietf.org/html/draft-cridland-hybi-upgrade-connect-00>. (Note,
> I do not necessarily mean adopt that whole proposal verbatim, just the extra
> CONNECT message as the first client->server packet after accepting 101.
> Server send does not have to wait on this fake CONNECT.)
>
> - I can live with correct routing information in the handshake, especially
> if we adopt David Cridland's fake-CONNECT-as-client-hello approach.
>
> "*where we can put the bar of an acceptable and good web sockets protocol*
> ",
> Salvatore Loretowww.sloreto.com
>
>
>
>
>
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 26 Dec 2010 18:17:25 +0100

* Maciej Stachowiak wrote:
>Cridland, is superior to vanilla GET+Upgrade, if there are no objections 
>to it. I believe his proposal is fully HTTP compliant, and does not add
>round trips. I would appreciate if we could check whether there are
>objections to that approach, from people who accept GET+Upgrade.
><http://tools.ietf.org/html/draft-cridland-hybi-upgrade-connect-00>.
>(Note, I do not necessarily mean adopt that whole proposal verbatim,
>just the extra CONNECT message as the first client->server packet after
>accepting 101. Server send does not have to wait on this fake CONNECT.)

You are not clear in what you are suggesting. Dave's proposal is to
throw in something that looks like a CONNECT request and then cross
fingers that buggy servers that fail to recognize Upgrade will stop
treating the stream as HTTP stream. It seems very clear that masking
is superior to that in terms of robustness, so you rather seem to be
saying you'd just like to use masking and also throw in a CONNECT-
like thing since that seems to maybe help and seems cheap enough.

I would think we would only do that if masking by itself is not ro-
bust enough (otherwise it would be an unnecessary complication), and
it does not seem we'll find consensus on masking that is not robust.
So while I think it was a mistake to not include Dave's proposal in
the straw poll, the question you are asking seems unlikely to arise.

You would have to show, for instance, how adding a CONNECT talisman
would make the protocol actually more robust (or offer some other
advantage) beyond "more is better" (clearly adding a pseudo-CONNECT
has a chance to further reduce the odds of an attack succeeding, but
so would making the masking key one byte longer, which we could do
ad infinitum, but we'd have to stop at some point).
-- 
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: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 26 Dec 2010 18:32:37 +0100

>bar of an acceptable and good web sockets protocol.

This is a bad poll. Among other things, you and Salvatore are asking
multiple slightly different questions, and you are mixing unrelated
things. For instance, masking and using GET in the handshake are quite
unrelated issues, but anyone who'd rather use a different method would
have to deal with a poll result about "GET" which inhibits discussion
about that.

Anyway, I do think some form of masking can address the robustness and
performance requirements people have brought up in a reasonable manner.
As I said a week ago, short of researching other suggestions, masking
and Dave Cridland's proposal seem to be the only viable ways forward.
-- 
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: Maciej Stachowiak <[email-masked]>
Date: Sun, 26 Dec 2010 21:30:57 -0800

> like thing since that seems to maybe help and seems cheap enough.

That's exactly what I'm saying.

> ad infinitum, but we'd have to stop at some point).

Both with regards to extending key length and with regards to adding a CONNECT talisman, HyBi WG members and other reviewers will have to make a judgment call on whether the extra robustness is worth the additional overhead and complexity. It is of course better if we can make such decisions informed by data, but I cannot volunteer to do any empirical study myself on this issue.

Masking, unlike CONNECT talisman, can be shown to have certain properties based on pure reasoning, so we are probably on more solid ground making judgments about it and its details.

Nonetheless, given the information available at present, I think CONNECT talisman is a net improvement to the protocol. I'm willing to change my mind based on data.

Regards,
Maciej

---

From: John Tamplin <[email-masked]>
Date: Mon, 27 Dec 2010 12:15:06 -0500

> ad infinitum, but we'd have to stop at some point).

I agree with what you are saying, though including a CONNECT in the
handshake has a one-time cost compared to adding one more byte to the
masking key which has a cost in every frame.

I personally don't think it is necessary given masking, but being a
cost only paid during the handshake I won't object to adding it if it
gets us to consensus.

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 28 Dec 2010 00:56:36 +0000

> I personally don't think it is necessary given masking, but being a cost only
> paid during the handshake I won't object to adding it if it gets us to consensus.

Yes, the one-time cost is not a deal-breaker. It may even have some benefit. The hard part is how to quantify it. If one could, then it might also be a justification to shave off some bits from  the per-frame key mask. Measuring this tradeoff and reasoning about it is a hard problem. Reasoning about masking by itself is simpler.

My concern is that I'm not sure we know enough. There may be potential downsides, e.g.,:

1. Presumably, the CONNECT will be in the clear (it's meant to be easily spotted so it can't be masked). This has been known to prevent connections that would otherwise happen. Salvatore and Willy know about some of these example deployments first hand:
http://www.ietf.org/mail-archive/web/hybi/current/msg05210.html
http://www.ietf.org/mail-archive/web/hybi/current/msg05211.html

...but there may be others. We don't know.

2. Adding CONNECT into the websockets protocol means that more end servers (web/ws servers) will see CONNECT than they currently do. This represents a brand new attack surface about which we know nothing about. 

#1 may reduce the number of connections from those possible by simply using masking. #2 may open up new issues and attacks. 

I'm not saying there couldn't be any benefit. It's just that it is very hard to quantify. I'm also saying that whatever benefits this CONNECT talisman may afford, the price is not just the extra one-time extra bytes. #1 and #2 are examples of additional price which is not currently known, but there may be others.