Subject: [hybi] Refinement of draft upgrade handshake

From: Greg Wilkins <[email-masked]>
Date: Tue, 12 Oct 2010 10:47:31 +1100

There appears to be 3 broad approaches being advocated for the handshake:

 1) refinement of the upgrade handshake as proposed in the current draft.
 2) A CONNECT based handshake
 3) A TLS/NPN based handshake.

I don't want to detract from options 2) or 3), but I think they should be
considered separately from discussion of 1).
So far all proposals to refine the current draft handshake have been lost in
a wide ranging debate that has covered 2 & 3 as well.

So I've started this thread with the intent of focusing on just 1 - and only
1 - and nothing but 1!!!! - to see if we can incrementally improve the
current upgrade handshake.  Once we have the best upgrade handshake that we
can design, we can  then  compare it to the handshake proposals produced for
2 or 3 (in other threads), and we can then pick the best of them (or more
than one).

So currently the proposals that I've seen that apply to the current draft
handshake are :

A) Use WS ping from the server and a WS pong from the client WS frames to
transport hashed nonces (rather than unframed bytes). This fixes the issue
with intermediaries not forwarding the unframed bytes on the wire and makes
the handshake comply with the requirement to be HTTP/1.1 compliant before
the 101 response.

B) Include a server nonce in the server sent ping, that the client must hash
and return in the pong.

C) Use a Hello frame type instead of ping/pong

D) Replace the char/space encoding of the client nonce with simple hex
encoding.

E) Define tight restrictions on the punctuation that can be sent in ws URLs
and subprotocols (eg prohibit use of : ) so that they cannot be used to
inject headers

F) Invert the framing MORE bit to be a FIN bit, so that WS control frames
will start with a non-ascii character

I think all of these are reasonable proposals and I'd be happy to write
diffs against the -02 draft for them

thoughts?

regards

PS. please keep your responses focused on what can be done in an upgrade
based handshake.

---

From: Scott Ferguson <[email-masked]>
Date: Mon, 11 Oct 2010 17:10:31 -0700

Greg Wilkins wrote:
> I don't want to detract from options 2) or 3), but I think they should 
> be considered separately from discussion of 1).
> So far all proposals to refine the current draft handshake have been 
> lost in a wide ranging debate that has covered 2 & 3 as well.
>
> So I've started this thread with the intent of focusing on just 1 - 
> and only 1 - and nothing but 1!!!! - to see if we can incrementally 
> improve the current upgrade handshake.  Once we have the best upgrade 
> handshake that we can design, we can  then  compare it to the 
> handshake proposals produced for 2 or 3 (in other threads), and we can 
> then pick the best of them (or more than one).
>
>
> So currently the proposals that I've seen that apply to the current 
> draft handshake are :
>
> A) Use WS ping from the server and a WS pong from the client WS frames 
> to transport hashed nonces (rather than unframed bytes). This fixes 
> the issue with intermediaries not forwarding the unframed bytes on the 
> wire and makes the handshake comply with the requirement to be 
> HTTP/1.1 compliant before the 101 response.
>
> B) Include a server nonce in the server sent ping, that the client 
> must hash and return in the pong.
>
> E) Define tight restrictions on the punctuation that can be sent in ws 
> URLs and subprotocols (eg prohibit use of : ) so that they cannot be 
> used to inject headers 
>
> F) Invert the framing MORE bit to be a FIN bit, so that WS control 
> frames will start with a non-ascii character

G) Change the "GET" to "WEBSOCKET" to allow admin authorization control, 
and enable fast rejection.

H) Add extension space in the Hello payload (or ping/pong) to enable a 
future challenge/response authentication extension.

-- Scott
>
>
> I think all of these are reasonable proposals and I'd be happy to 
> write diffs against the -02 draft for them
>
> thoughts?
>
> regards
>
> PS. please keep your responses focused on what can be done in an 
> upgrade based handshake.
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 12 Oct 2010 12:12:51 +1100

> and enable fast rejection.

I'd like to make the use of a WEBSOCKET method along the following lines:

A websocket client MAY use any legal HTTP method for the hand shake.  The
'WEBSOCKET' method SHOULD be used by WebSocket clients that can handle only
the responses specified in this RFC. Web Socket Client MUST NOT use other
methods unless they are capable of handling the HTTP responses that may be
returned by a server that does not support WebSocket.  For example, if the
GET method is used, then a client MUST be able to handle a 200 response with
content for the get.

> future challenge/response authentication extension.

We could specify "first 8 bytes" etc. of the payload, but we have to be
cautious about allowing (or ignoring) arbitrary additional content as this
may weaken defences against inject or detection of fraudulent Hello's.
Maybe authentication can be in frames after the Hello, or in the extension
space already allowed by framing?

cheers

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 11 Oct 2010 19:17:46 -0700

On Oct 11, 2010, at 4:47 PM, Greg Wilkins wrote:

> I don't want to detract from options 2) or 3), but I think they should be considered separately from discussion of 1).
> So far all proposals to refine the current draft handshake have been lost in a wide ranging debate that has covered 2 & 3 as well.
> 
> So I've started this thread with the intent of focusing on just 1 - and only 1 - and nothing but 1!!!! - to see if we can incrementally improve the current upgrade handshake.  Once we have the best upgrade handshake that we can design, we can  then  compare it to the handshake proposals produced for 2 or 3 (in other threads), and we can then pick the best of them (or more than one).

You are welcome to invest your own efforts however you like. But I think proceeding in this order would be a poor use of time for the Working Group overall, since (2) and (3) have much more promising security properties than (1). I don't see why we should focus on improving the weakest candidate first.

I at least would object to declaring consensus on (1) while the broader discussion is still ongoing.

Regards,
Maciej

---

From: John Tamplin <[email-masked]>
Date: Mon, 11 Oct 2010 22:27:21 -0400

On Mon, Oct 11, 2010 at 10:17 PM, Maciej Stachowiak <[email-masked]> wrote:

> You are welcome to invest your own efforts however you like. But I think
> proceeding in this order would be a poor use of time for the Working Group
> overall, since (2) and (3) have much more promising security properties than
> (1). I don't see why we should focus on improving the weakest candidate
> first.
>

One question we need to ask is what time frame we are trying to get the spec
done in -- if we want to get it in soon, then I don't think TLS/NPN is an
option at all.  That leaves variations on #1 or #2 (or some combination).

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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 12 Oct 2010 04:37:16 +0200

* Maciej Stachowiak wrote:
>proceeding in this order would be a poor use of time for the Working
>Group overall, since (2) and (3) have much more promising security
>properties than (1). I don't see why we should focus on improving the
>weakest candidate first.

Greg did not propose to proceed in any particular order, proponents for
the other options are very welcome to discuss those in separate threads.
That would indeed seem to be necessary as there is a good bit of con-
fusion around some of the options, for instance, Ian Hickson suggested
that NPN would allow us to drop one of the two URI schemes, while others
expect to have both available to allow for self-signed certificates. But
that's something for a different thread.
-- 
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: Mon, 11 Oct 2010 19:46:23 -0700

On Oct 11, 2010, at 7:27 PM, John Tamplin wrote:

> One question we need to ask is what time frame we are trying to get the spec done in -- if we want to get it in soon, then I don't think TLS/NPN is an option at all.  That leaves variations on #1 or #2 (or some combination).

Do you mean there is some technical obstacle to writing the spec and/or deploying the code for a TLS/NPN solution quickly? Or do you just mean it would take longer to make it 100% official, since NPN itself would need to progress along the standards track?

At this point, I think the key factor is coming to consensus on something quickly and speccing it in enough detail to get interoperable implementations quickly. Otherwise we may end up stuck with -76.

Regards,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 12 Oct 2010 13:50:14 +1100

On 12 October 2010 13:46, Maciej Stachowiak <[email-masked]> wrote:
>
> Do you mean there is some technical obstacle to writing the spec and/or
> deploying the code for a TLS/NPN solution quickly? Or do you just mean it
> would take longer to make it 100% official, since NPN itself would need to
> progress along the standards track
>

Maciej,

Can you please take the discussion of TLS/NPN to another thread!

As Bjoern said, I've proposed no order and I encourage those that advocate
alternative handshakes to prepare firm proposal for them.

I'd like this thread to be about what's  the best we can do with Upgrade.
  We need to defer the "this handshake is better than that handshake"
discussion until we have actually refined the various proposals.

regards

---

From: John Tamplin <[email-masked]>
Date: Mon, 11 Oct 2010 22:50:16 -0400

On Mon, Oct 11, 2010 at 10:46 PM, Maciej Stachowiak <[email-masked]> wrote:

> progress along the standards track?
>

I haven't followed the TLS discussions recently, but it seems like it was as
contentious as the discussions here -- achieving consensus on two things is
harder than one and takes more time.

> At this point, I think the key factor is coming to consensus on something
> quickly and speccing it in enough detail to get interoperable
> implementations quickly. Otherwise we may end up stuck with -76.
>

I agree we need to get something done soon if we are to avoid v76 being
long-lived in the wild.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 Oct 2010 07:17:15 +0200

Hi Greg,

> 2 or 3 (in other threads), and we can then pick the best of them (or more

That's a good approach in my opinion.

> will start with a non-ascii character

G) prepend the first message in each direction with bytes that are
   not possible in HTTP, such as 0x00 0xFF. This would be sort of a
   "start sequence" before the ping/pong or hello.

Regards,
Willy

---

From: John Tamplin <[email-masked]>
Date: Tue, 12 Oct 2010 10:06:10 -0400

One other point to consider is that since we have missed the 4-week
deadline we discussed in July, currently most browsers either are or
will soon be shipping with support for v76.  So, that handshake is
going to start getting used in lots of web apps, with whatever flaws
it has.

Since that is already going to be present in shipping browsers so any
cross-protocol attacks it enables will be possible regardless of what
we do here (until that support is removed in future versions, which
may be hard), does it make sense to codify it and at least get the
benefit of the other work we have done here?

To be specific, I propose the following:
 - define the spec with mostly the current handshake plus whatever
improvements we can agree to quickly, name the schemes wsupgrade and
wssupgrade
 - develop an alternate handshake that is better or use TLS/NPN is
available, defining ws and wss schemes.
 - as servers support the alternate handshake, get browsers to remove
wsupgrade/wssupgrade

If we don't do something now, I fear that as Anne suggests it may be
very hard to ever get rid of v76 in the wild.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 12 Oct 2010 10:34:36 -0400

On Mon, 2010-10-11 at 19:46 -0700, Maciej Stachowiak wrote:
> Or do you just mean it would take longer to make it 100% official,
> since NPN itself would need to progress along the standards track? 

(just for clarity: I'm not the "you" in the quote)

I think NPN will take a very long time. Part of that is the standards
track process, but the bigger issue is the separability of TLS from
HTTP.

Consider a hardware accelerator device like the F5 Big-IP. It is
extremely common for corporate data centers to terminate all SSL in such
a device (or one from one of a dozen competitors). To deploy websockets
via TLS/NPN requires an update on the HTTP server to grok websockets as
well as a firmware update on the accelerator. It isn't enough to bundle
an updated OpenSSL into whatever python/ruby/etc framework is being used
to implement websockets on the application server, the NPN handshake
will die at the accelerator if that device is not also updated. (that's
my understanding - I welcome a correction of course).

And updating that device is, in practice, a big deal. First we need to
presume the availability of firmware updates for all of these
accelerators (and there are many). Some of the appliances no longer even
receive updates (perhaps the vendor is out of business, has eol'd the
product, or there is no support contract) but still manage to serve
their purpose in life quite well and go on operating in blissful
ignorance. 

Which brings me to the second point, these devices and their policies
are typically not "owned" in an organization by the same people that
"own" the application software. Getting their agreement to do an upgrade
to a security device that likely serves a wide range of different
applications is a slow process and there better be a big payoff for the
risk involved. It is a barrier to implementation that WS doesn't need.

You might say - "just route around the SSL accelerator". First, you
would have to do that based on L4 information and in a virtual hosting
environment that is not enough information to make the route decision
on. Second, to do so likely violates local policy. These accelerators
were bought for a reason (perhaps for audit compliance, perhaps for
web-app-firewall capabilities, perhaps for performance) and the
corporate security policy officers will not willy nilly sign off on an
opaque end to end tunnel. Citing the NULL suite doesn't help here as
that might not be a desirable end to end property.

The WG can debate whether that makes any sense or not - but it doesn't
matter in a practical sense because such bifurcated responsibilities
exist and create significant friction to deployments that aren't plug
and play on existing infrastructure. I worked in the server-side
appliance space for years, and the operational relationships are
complicated.

One of the WG goals is to be able to use the two-true-ports (80/443) and
be compatible with the existing infrastructure in doing so. NPN breaks
that goal. Connect/Upgrade are more realistic options for a successful
protocol at this point in time.

(Greg, I apologize that I posted this in the wrong thread.)