Subject: [hybi] It's time to ship

From: Adam Barth <[email-masked]>
Date: Sun, 9 Jan 2011 14:21:44 -0800

Gentle people of hybi,

There's been a lot of good discussion in this working group gathering
consensus around the data framing and the handshake.  At some point we
need to declare victory and ship the protocol, otherwise proprietary
solutions will continue to eat our lunch.

I've written up a more formal version of Pat's proposal based on the
recent straw poll and subsequent discussion.  This protocol is by no
means perfect, but it's good enough:

http://www.ietf.org/id/draft-abarth-thewebsocketprotocol-01.txt

As a working group, it's time to ship.

Kind regards,
Adam

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 9 Jan 2011 23:42:28 +0100

Hello Adam,

> http://www.ietf.org/id/draft-abarth-thewebsocketprotocol-01.txt

It would help a lot other WG participants if you could present suggestions,
ideas and changes instead of a full proposal. It's hard to spot the proposed
changes.

At first glance, I'm noticing a few things :

  - you're using the OPTIONS method. The WG's consensus was voted as using
    GET. While technically working, OPTIONS limits some possibilities since
    no path is sent to the server.

  - your proposal involves AES-128-CTR. As was discussed here, it seems there
    are still export regulations for certain countries eventhough they're
    apparently fading out. It could still be a problem for companies who want
    to export products to some countries and which never had to put crypto in
    them.

  - several people on the list asked for the ability to be able to disable
    the masking in some well-controlled environments (eg: server-to-server
    communications). I see no provisions for this.

  - it has not yet been stated whether only the payload or also the framing
    should be masked. Your proposal masks both, which means that it definitely
    blocks any possibility of performing multiplexing later. There does not
    appear to have been a consensus in this area yet.

  - is was suggested that some (all ?) of the nonces could go away if masking
    is used. Surely this is something that needs to be rechecked.

  - Greg proposed to replace the MORE bit with a FIN bit so that the first
    hello frame from the server starts with a high bit set, thus ensuring
    that we can break the connection on non-HTTP compliant intermediaries
    which would expect a second response after the 101.

Those are just a few notes, it's really not easy to changes :-/

Thanks for this work,
Willy

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

---

From: Adam Barth <[email-masked]>
Date: Sun, 9 Jan 2011 14:49:10 -0800

> ideas and changes instead of a full proposal. It's hard to spot the proposed

We've had plenty of suggestions, ideas, and changes.  It's time to ship.

>    no path is sent to the server.

Be that as it may.  OPTIONS is good enough.

>    to export products to some countries and which never had to put crypto in

Frankly, the export restriction issue is a bunch of BS.  AES-128-CTR
is good enough.

>    communications). I see no provisions for this.

The protocol is good enough without this added flexibility.  If we
find this is really important, we can add this ability in a future
version of the protocol.

>    appear to have been a consensus in this area yet.

The protocol is good enough without this added flexibility.  If we
find this is really important, we can add this ability in a future
version of the protocol.

>    is used. Surely this is something that needs to be rechecked.

I have checked this issue.  Each nonce in the protocol serves a
specific purpose and is valuable.

>    which would expect a second response after the 101.

The protocol is good enough without this change.  The masking has us
covered here.

Kind regards,
Adam

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 10 Jan 2011 00:02:29 +0100

> We've had plenty of suggestions, ideas, and changes.  It's time to ship.

Yesterday, Sal said that there were a number of points to discuss yet, why
this sudden hurry ?

> Be that as it may.  OPTIONS is good enough.

But on what basis are you trying to change what was adopted as a consensus ?
I mean, I *know* that OPTIONS can evict more broken intermediaries than GET,
but the participants here have been working on the GET hypothesis with its
capabilities. Noone has had the opportunity to talk about their expectations
and the implications such a change would have for them.

> Frankly, the export restriction issue is a bunch of BS.  AES-128-CTR

Good enough for what purpose precisely ? HTTP Upgrade is good enough for
Websocket without even any form of masking. Masking was added to address
specific issues that aren't precisely quantified.

> find this is really important, we can add this ability in a future

No, it will be too late because it will never be possible to mix masked
and non-masked frames later since there will be no way to distinguish them.

> find this is really important, we can add this ability in a future

Adam, please I can understand that you're in a hurry, but you have
copy-pasted exactly the same response as to the question above. I would
have found it more polite to respond later when you have more time.

> specific purpose and is valuable.

Then would you please take care of explaining them to us in this context
when you have more time ?

> The protocol is good enough without this change.  The masking has us

No, I'm talking about the ability to ensure that a non-compliant intermediary
will fail early instead of remaining stuck waiting for the server to talk.
That once one of Hixie's major concerns and one of the reasons for the Hello
frames suggestion.

Regards,
Willy

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 09 Jan 2011 15:06:12 -0800

> and the implications such a change would have for them.

Now seems like a fine time to discuss OPTIONS. What are the pros and cons? It seems to avoid the HTTP compliance issues that CONNECT had, at least.

Regards,
Maciej

---

From: Adam Barth <[email-masked]>
Date: Sun, 9 Jan 2011 15:09:26 -0800

On Sun, Jan 9, 2011 at 3:06 PM, Maciej Stachowiak <[email-masked]> wrote:
> Now seems like a fine time to discuss OPTIONS. What are the pros and cons?
> It seems to avoid the HTTP compliance issues that CONNECT had, at least.

Whether we use OPTIONS or GET is much less than 1% of the value
proposition of the WebSockets protocol.  Rather than optimizing that
part of the protocol, it's more important to pick something and go
with it.

Honestly, I picked OPTIONS because it was the example given in
http://www.ietf.org/rfc/rfc2817.txt.

Adam

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 09 Jan 2011 15:10:09 -0800

> That once one of Hixie's major concerns and one of the reasons for the Hello

Is there any evidence that either client-->server or sever-->client HELLO frames would reduce the rate of apparent successful connections that later fail in real-world deployment? If so, we can consider adding them on their own merits.

Regards,
Maciej

---

From: Adam Barth <[email-masked]>
Date: Sun, 9 Jan 2011 15:11:52 -0800

> Yesterday, Sal said that there were a number of points to discuss yet, why

There is no sudden hurry.  WebSockets have already been delayed far
too long.  It's time to ship.

Adam

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 09 Jan 2011 15:12:44 -0800

> http://www.ietf.org/rfc/rfc2817.txt.

I personally have no objections to OPTIONS. The reason for this side thread is so that anyone who has a concrete problem with OPTIONS can raise it now. I'm not aware of any such problems, but Willy said there might be some. I'm definitely into shipping soon, but it can't hurt to be informed.

Regards,
Maciej

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 10 Jan 2011 00:18:08 +0100

> Now seems like a fine time to discuss OPTIONS. What are the pros and cons? It seems to avoid the HTTP compliance issues that CONNECT had, at least.

Yes, OPTIONS+101 is equivalent for servers to what CONNECT is for proxies.
It has been evocated a bit in the past, but the discussion quickly ended and
nobody gave his opinion.

The pros is that some intermediaries unaware of the Upgrade mechanism will
respond themselves with 405, 501 or 200 depending on whether they support
it or not, which will cause a cleaner failure.

The cons is that it removes the ability to use any form of path in the
request, so you can only rely on the server name. Sure that's a lot better
than relying on its IP address, but it might not fit everyone's use. I can
live with it if required, as I've said several times in the last few months.
However, you once expressed concerns on this point about the ability to
forge OPTIONS requests using XMLHttpRequest (which I did not know were
possible).

The point is that it was said yesterday to one guy that once a consensus is
achieved, it must not be revisited, and now we're doing exactly that :-/

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 10 Jan 2011 00:24:22 +0100

> Is there any evidence that either client-->server or sever-->client HELLO frames would reduce the rate of apparent successful connections that later fail in real-world deployment? If so, we can con…

Yes, we had several examples in the past of intermediaries which don't know
about the specifics of the 101 status code and which process it as 100, as
the HTTP spec says that if you don't know how to handle code XYZ, you can
handle it as X00. The problem is that 100 is an intermediate response, which
indicates that another one will come after it. So the intermediary sends the
headers to the client and waits for the server to talk, doing nothing else.

Older versions of haproxy used to do that because I implemented the RFC as
I had read it. It was only after joining the WG that I discovered the magics
of 101. Apache does that too. But Apache takes OPTIONS requests for itself,
so a GET+101 on apache will require a hello frame while an OPTIONS will
immediately be rejected, so for this one it's irrelevant.

In fact I'd be more worried about load balancers and content switches
in general. They have to support 100 because of the very common
"Expect: 100-Continue" that is present in many POST requests, and it's
highly likely that they'll process 101 as a 100 just as haproxy did,
because 101 was part of RFC2817 and not 2616.

So yes, for this matter, the hello frames will really help quickly
terminate connections through failed intermediaries instead of leaving
them hanging.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Jan 2011 00:39:36 +0100

On 10.01.2011 00:09, Adam Barth wrote:
> ...
> ...

OPTIONS isn't special with respect to Upgrade. (*)

My understanding is that the authors picked this example in order to 
avoid to let the server ignore the Upgrade request in GET, and then 
return the contents over an non-secured channel.

Unless there's a specific reason why people think OPTIONS is better than 
GET here, we should stick with what was discussed before.

Best regards, Julian

(*) I may be wrong, in which case we should clarify this in HTTPbis.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Jan 2011 00:40:45 +0100

> live with it if required, as I've said several times in the last few months.

Hmmm? OPTIONS can have a path just like any other method.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Jan 2011 00:42:33 +0100

> because 101 was part of RFC2817 and not 2616.

This is incorrect, see 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.1.2>.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 10 Jan 2011 00:44:13 +0100

> Hmmm? OPTIONS can have a path just like any other method.

Oh yes Julian, you're making a good point, in fact I got fooled by the
"OPTIONS *" request. Yes indeed, with a path OPTIONS becomes equivalent
to GET and is forwarded.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 10 Jan 2011 00:46:38 +0100

> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.1.2>.

OK, but that's not what I'd call a definition. It's just as little verbose
as CONNECT, it lets one imagine it's just to use a new HTTP version. Both
were given an example for the first time in 2817 in my opinion.

Thanks for the reminder anyway ;-)
Willy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Jan 2011 00:50:12 +0100

> were given an example for the first time in 2817 in my opinion.

Well, there's also the text in 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.42>.

So... we recently adopted language from 2817 into HTTPbis; could you 
please check that, and provide feedback to the WG if you feel we need to 
improve what we have?

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 10 Jan 2011 00:55:45 +0100

> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.42>.

Yes I know, but the connection between 101 and Upgrade was not easy to
establish. I discovered that particularity here with websocket for the
first time after 10 years of everyday use of HTTP.

> please check that, and provide feedback to the WG if you feel we need to 

I remember having checked that part in http-bis, as I was one of those
asking for the merging of CONNECT and 101 into http-bis, and found it to
be OK. I could recheck though. But it's always harder to spot things that
are difficult to understand once you know them. I'd better ask someone
else to indicate me if he understands how to use it.

Cheers,
Willy

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 10 Jan 2011 01:39:44 +0100

> http://www.ietf.org/id/draft-abarth-thewebsocketprotocol-01.txt

I cannot agree this proposal.

I would only accept a cryptographic masking algorithm if it is applied
as an extension (mandatory for browsers) that can be replaced by other
algorithms
I would only accept stream based masking if it does not apply to framing.

If we were to follow John Tamplins prior proposal, then I'd accept
AES-128-CTR (or similar) if that was the consensus, but my preference
is still for something simpler.

regards

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 9 Jan 2011 16:42:28 -0800

On Jan 9, 2011, at 3:39 PM, Julian Reschke wrote:

> My understanding is that the authors picked this example in order to avoid to let the server ignore the Upgrade request in GET, and then return the contents over an non-secured channel.
> 
> Unless there's a specific reason why people think OPTIONS is better than GET here, we should stick with what was discussed before.

OPTIONS is the appropriate method to use when the client
does not want the action taken to be retrieval of a
representation, especially when the resource might be
subject to hit counting (like an advertisement).

OPTIONS is preferred when you don't want the server to
provide an old-version response during an Upgrade, since
it has no negative implications for a compliant server.
Websocket should use OPTIONS for HTTP if it is not going
to mint a new method of its own.

....Roy

---

From: Adam Barth <[email-masked]>
Date: Sun, 9 Jan 2011 16:46:17 -0800

> I cannot agree this proposal.

Thanks for your feedback.  I'd encourage you not to implement this
protocol then.

Kind regards,
Adam

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 10 Jan 2011 01:47:01 +0100

> to mint a new method of its own.

Thanks for this precision Roy. However, my initial remark was more
for the "*" than OPTIONS itself (eventhough I mentally associated
them both).

"*" undoubtly has pros but it has cons too. A consensus was reached
on GET yesterday afer something like one month of poll. It's a bit
hard that a counter proposal is made the day after the consensus
that way.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 10 Jan 2011 01:51:35 +0100

> Thanks for your feedback.  I'd encourage you not to implement this

Adam, excuse me, but you remained silent for the last days during
discussions where you could have brought many strong points, and
you suddenly come here acting as if you were the only one to decide
what will be in the final draft, and deliberately deciding to ignore
the WG's pariticipants' concerns.

I can understand that you had some work, I can understand that you're
fed up with things that are constantly delayed, but one reason it
takes so much time to move on here is that from time to time all that
was agreed upon is suddenly put upside down.

It's really not easy to work that way.

You really sound like you have a big hurry or you are afraid of something
imminent related to the protocol (you were talking about proprietary
designs in your first mail). If you have more info to put here, surely
will help people understand better your motives.

Thanks,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Jan 2011 01:56:11 +0100

> subject to hit counting (like an advertisement).

Which would be relevant if the URI used for websockets *also* functions 
as something people could do a GET on and receive something useful 
(other than an error message explaining what's going on) -- I think that 
would be simple to avoid.

> to mint a new method of its own.

Ack. I have no problem with that as long as it's understood why the spec 
makes that choice.

For simplicity, the best *server* side choice IMHO is to treat Upgrade 
the same way for a given URI, no matter what what request method was.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 9 Jan 2011 17:17:59 -0800

On Jan 9, 2011, at 4:56 PM, Julian Reschke wrote:
> For simplicity, the best *server* side choice IMHO is to treat Upgrade the same way for a given URI, no matter what what request method was.

No, the value of upgrade is similar to conditional GETs:
asking for an optional improvement to the protocol without
costing an extra round trip.  The common case is a normal
GET request, and the server responds to that GET request
as its first message after the protocol is upgraded,
without any further bits needed from the client.

IOW, waka (or some future HTTP/2.0) can be bootstrapped
at near-zero cost with Upgrade because waka knows how
to respond to the semantics of GET.  The same applies to
any other valid HTTP method -- the server must provide a
valid answer to that request, in the syntax of the new
protocol, after the 101 is sent (see 2616 sec 14.42).

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 9 Jan 2011 17:33:59 -0800

> hard that a counter proposal is made the day after the consensus

Yes, it's a bit hard.  OTOH, the poll was nonsense because it
conflated multiple undesirable options, and I ignored it as such.

In any case, the IETF does not make decisions by polling.  

What we are looking for is rough consensus and running code,
and it is quite clear that we don't have either one at the moment.
We should not be making any decisions -- we should be in bake-off
mode.

....Roy

---

From: Adam Barth <[email-masked]>
Date: Sun, 9 Jan 2011 17:41:54 -0800

> We should not be making any decisions -- we should be in bake-off

Perhaps I should have titled my message "it's time to bake."  :)

Adam

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Sun, 9 Jan 2011 22:08:13 -0800

>    no path is sent to the server.
I agree it is important to be able to identify between various resources on
a server. E.g. for our use, we will have multiple different websocket
endpoints, and we want our frontend to be able to dispatch to the
appropriate backend based on the information in the handshake. That said, I
think the draft allows for that (Sec-WebSocket-URL), or as pointed out on
another thread, it appears OPTIONS does allow for a path component. So, I
think we should be able to resolve that point.

>    to export products to some countries and which never had to put crypto

It would be nice to understand if this is actually a hard constraint.
AES-128-CTR has the benefit of being well understood, as well as fast, as
demonstrated by Maciej in another thread. That said, I don't care strongly
one way or another here.

>    communications). I see no provisions for this.
There's nothing that would prevent you from writing an extension that would
disable the masking, from my understanding.

>    appear to have been a consensus in this area yet.
I'm not sure why this would block the possibility of multiplexing. I would
agree that would be a problem if it were the case. However, a number of the
early proposals for multiplexing included something like a stream-id in the
frame. This could still be present. Though it would be masked, so would the
length and other things that a meaningful intermediary would care about, so
assuming the intermediary was capable of un-masking, is this an issue?

>    which would expect a second response after the 101.
The draft Adam sent out is based on an intermediate version I had checked
into SVN, back when it looked like we were gaining speed on CONNECT. I
didn't yet get around to flipping MORE/FIN, but I don't have any ojbections
to this.

> Those are just a few notes, it's really not easy to changes :-/

There's a tool on the IETF to diff drafts. I find it quite helpful, that
said, a lot of text has changed because I had already started to make other
requested changes (including trying to resolve the HTTP compliance issue, by
stating the requirements of the handshake rather than stating send X bytes,
send Y bytes, ...). This makes the diff a bit harder to interpret, for sure.

That said, I do hope that this can spur some more targeted conversations and
drive progress.

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 10 Jan 2011 07:24:31 +0100

> disable the masking, from my understanding.

By masking the framing, the masking inherently becomes part of the framing.
Intermediaries will need to be written that understand the masking,
just so that they can parse the framing.

Thus you cannot turn masking off unless you modify every WS component
in the chain with knowledge of the no-masking extension.

The whole point of extensions was to allows opaque extension data to
be associated with frames so that it is only handled by components
that care about it.

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 10 Jan 2011 07:28:59 +0100

> Thanks for your feedback.  I'd encourage you not to implement this

Check the attitude mate!

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 10 Jan 2011 07:38:58 +0100

On 10 January 2011 01:56, Julian Reschke <[email-masked]> wrote:
>
> For simplicity, the best *server* side choice IMHO is to treat Upgrade the
> same way for a given URI, no matter what what request method was.

+1

The client should use another method (eg GET), only if it is prepared
to accept a valid response to that method (or the consequences on the
server of a PUT/POST/etc.) if the upgrade is not accepted (or is
discarded by an intermediary).

WS will be used in situations where fall back transports (eg long
polling) will be used if ws is not supported.  To avoid extra round
trips it is desirable that a failed WS handshake be able to be used as
part of the initiation of such a fallback prototocol.

I fully understand that such a fallback would need support in the
browser API, an that will not be coming any time soon, but that is no
reason to deny this approach in the protocol for the future or for non
browser clients.

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 10 Jan 2011 07:50:03 +0100

> assuming the intermediary was capable of un-masking, is this an issue?

I don't think it makes multiplexing impossible - just more difficult,
more complex and more invasive.

Multiplexing can no longer be just a channel label associated with
each frame in a stream, because a frame stream will only be meaningful
in the context of keys exchanged by a client and a server.
Thus the key exchange will no longer be able to be end to end, and the
multiplexer will need to be then end point of each connection from a
client, so that it can initiate a new shared connection with a server
with a new and different stream key applied to it. You then have to
avoid the  situation where the multiplexer has accepted a WS
connection that the server does not want to accept - argh!

all this for no actual benefit???

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 10 Jan 2011 07:54:08 +0100

Hello Ian,

> think we should be able to resolve that point.

Once again,I'm not opposed at all to this point. I'd even say that would it
not have been accepted as a consensus in the last poll, I'd probably have
voted for it. It's just that it's a change from what was planned till now
and participants need to express their opinion on that point.

> demonstrated by Maciej in another thread. That said, I don't care strongly

One of my issue with it is that despite being fast, it's a lot slower than
simpler masking. I design software components to be used at the border side
of infrastructures to dispatch the traffic to multiple servers, and I'm
very much concerned by the performance limitations. On a machine which has
normally no issue processing 10 Gbps of HTTP, I could not even process 1 Gbps
of WebSocket with large contents. This is much concerning because it implies
that in order to build the stream analysers we've talked about in the past,
it will become mandatory to install expensive crypto acceleration cards. This
is not logical for a protocol which is supposed to be transferred in clear
(ws:// as opposed to wss://). Checking for forbidden words, dangerous links
or forbidden contents on campus sites will be much more expensive due to this
masking algorithm alone.

> disable the masking, from my understanding.

Adam did not seem favorable to that.

> assuming the intermediary was capable of un-masking, is this an issue?

Yes, and you got the point : if the ID is masked, how to you know which
stream it is in order to pick the right unmask key ? At least the stream
ID will have to be unmasked. If we prepend it before the frame, it means
a new framing format. Till not it was suggested to have it in the frame.

> didn't yet get around to flipping MORE/FIN, but I don't have any ojbections

OK.

> send Y bytes, ...). This makes the diff a bit harder to interpret, for sure.

Ah, OK. Till now I'd only use the automated diffs between incremental drafts,
I did not know that there were other tools.

Regards,
Willy

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 10 Jan 2011 10:15:05 +0100

> Thanks for your feedback.  I'd encourage you not to implement this

Note also that this discussion is not about implementation.

If browsers implement some protocol, then the servers and
intermediaries will do their best to support it as we have always
done, no matter how ill conceived the ideas or how little the server
side concerns have been considered.

But implementation is entirely different to standardisation, which is
the point of the discussions here.   The get standardisation at the
IETF, you need consensus from all the main constituencies and from the
wider IETF community.  If the browser vendors chose to ignore the
concerns of the intermediaries and server side, that does not make
those concerns go away - they remain and almost certainly means will
be found to address them that will in all probability be proprietary
and/or disparate, thus making the chances of WS becoming an IETF
standard even less likely.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Mon, 10 Jan 2011 10:16:09 -0800

On Sun, Jan 9, 2011 at 10:54 PM, Willy Tarreau <[email-masked]> wrote:

> > >    to export products to some countries and which never had to put
> crypto
> > > in
> > >    them.
> > >
> >
So, you're saying that with the XOR masking where the entire content
required to unmask the frame was included in the frame, it would be easier
for an intermediary to thus examine the frame? I agree that it would be
easier, and that in the AES method it would require an intermediary to be
"active" instead of "passive", e.g. terminate the connection at the
intermediary. I personally think that's a good argument towards XOR, but am
personally not heavily invested either way as I think for our uses, we would
be terminating at the "intermediary" anyways.

> I did not know that there were other tools.
http://tools.ietf.org/rfcdiff :)

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Jan 2011 18:20:25 +0000

2011/1/10 Ian Fette (イアンフェッティ) <[email-masked]>:
>> > >    apparently fading out. It could still be a problem for companies
>> > > who
>> > > want

Ian,

Im not sure Im following the reasoning here: why does the AES
mechanism (which is,
after all, just an XOR with a long, randomly computed mask) require an
active intermediary?

Thanks,
-Ekr

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Mon, 10 Jan 2011 10:25:31 -0800

2011/1/10 Eric Rescorla <[email-masked]>

> >> > I agree it is important to be able to identify between various
> resources
> >> > on
> >> > another thread, it appears OPTIONS does allow for a path component.
> So,
> >> > I
> >> > >  - your proposal involves AES-128-CTR. As was discussed here, it
> seems
> >> > > there
> >> > >    blocks any possibility of performing multiplexing later. There
> does
> >> > > not
> >> > agree that would be a problem if it were the case. However, a number
> of
> >> > the
> >> > early proposals for multiplexing included something like a stream-id
> in
> >> > the
> >> > frame. This could still be present. Though it would be masked, so
> would
> >> > the
> >> > length and other things that a meaningful intermediary would care
> about,
> >> > so

I guess you're right in that it wouldn't require the intermediary to be
active. It would however require the intermediary to maintain state for each
connection, correct? (As opposed to XOR where the intermediary could be
mostly stateless as the the "masking key" would be embedded in the frame).
How large is the state that would need to be maintained?

-Ian

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Jan 2011 18:55:21 +0000

> How large is the state that would need to be maintained?

Basically the AES key schedule, which is pretty small (4k for a
speed-optimized version)
plus as much of the frame as you buffer [the whole thing if the key is
at the end, obviously.]

-Ekr

---

From: Bruce Atherton <[email-masked]>
Date: Mon, 10 Jan 2011 13:32:25 -0800

Adam,

I've read over your protocol spec. I've carefully considered it, and 
I've decided I will not use it in any application I design. There are 
always alternatives. I will use something that is better suited to my needs.

I'd offer more constructive feedback but I am convinced I will be ignored.

I wish you all the best with shipping your protocol. I am sure many 
people will be very interested in it.

Sincerely, Bruce.

On 09/01/2011 4:46 PM, Adam Barth wrote:
> On Sun, Jan 9, 2011 at 4:39 PM, Greg Wilkins<[email-masked]>  wrote:
>> On 9 January 2011 23:21, Adam Barth<[email-masked]>  wrote:
>>> Gentle people of hybi,
>>>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 12 Jan 2011 21:28:28 +0100

>http://www.ietf.org/id/draft-abarth-thewebsocketprotocol-01.txt

This says:

  The masked-data is the clear-text frame encrypted under AES-128-CTR
  (see [TODO: Cite AES-128-CTR]) using the masking-key as the key and
  the initial counter value equal to the masking-nonce followed by 28
  zero octets.

  For example, octet i of the masked-data is computed from octet i of
  the clear-text frame as follows:

    initial-counter = masking-nonce << 96
    masked-octet-i = clear-text-octet-i XOR AES_k(initial-counter + i)

  where AES_k is AES keyed with the masking-key.

Could you give a reference for AES-128-CTR and explain the example?
-- 
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: Adam Barth <[email-masked]>
Date: Wed, 12 Jan 2011 13:15:15 -0800

> Could you give a reference for AES-128-CTR and explain the example?

Here's an example RFC that uses AES-128-CTR

http://www.ietf.org/rfc/rfc4344.txt

I believe it's technically defined by combining
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf and
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf, the
later of which contains test vectors.  (Careful readers will notice
that my example is wrong.)

Adam

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 13 Jan 2011 00:47:34 +0100

>that my example is wrong.)

I agree your example is wrong. So the concern was a chosen ciphertext
attack. For simplicity let's say Websocket frames are just 16 byte long
blocks and the attacker has full control over them. From the same 16
byte input the browser would generate at most 2^32 ciphertexts, so an
attacker can compute the masked frame for one of the nonces and send it
over and over again, eventually his ciphertext will appear.

Example: The handshake establishes the per-connection key K, I want to
put "0123456789ABCDEF" on the wire, I compute "0123456789ABCDEF" `xor`
AES(K, 0x12345678000000...) and ask the browser to send that again and
again; eventually it will pick 0x12345678 as per-frame nonce, it will
xor with the same AES value, and I get my attack payload on the wire
(if the block counter is not reset, I'd just take that into account by
recomputing the masked frame still assuming the same per-frame nonce.)

So is there an error in this analysis, or is the argument simply that
using your AES scheme seems to make attacks a little bit harder?
-- 
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: Adam Barth <[email-masked]>
Date: Wed, 12 Jan 2011 16:05:04 -0800

> using your AES scheme seems to make attacks a little bit harder?

That's not really a chosen ciphertext attack.  A chosen ciphertext
attack means something specific in cryptography:

http://en.wikipedia.org/wiki/Chosen-ciphertext_attack

Your overall point is correct, however.  The security of the masking
depends on the size of the per-frame nonce.  That's the case for each
of the masking proposals.  32 bits seems like a reasonable trade-off
between security and per-frame size overhead.  With a 32 bit nonce,
you'll have to try this attack 2,147,483,648 times (on average) before
it works (that's around 2 billion).

Adam

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 13 Jan 2011 18:09:19 +0900

> that my example is wrong.)
So, this part can be rewritten like this, I thought. do you think it's
correct?

----
...[snip]
   the initial counter value equal to the masking-nonce followed by 12

...[snip]

  initial-counter = masking-nonce << 96
  for i = 0 to size-of-clear-text - 1
    j = i MOD 16
    if j == 0
      frame-key = AES_k(initial-counter + i / 16)

    masked-octet-i = clear-text-octet-i XOR octet-j-of-frame-key
----

and, since masking-key is 20 octet length, it looks like we must
truncated/padded key to fit AES key size?

---

From: Adam Barth <[email-masked]>
Date: Thu, 13 Jan 2011 01:25:36 -0800

> truncated/padded key to fit AES key size?

Something like that.  Luckily we have crypto experts to help us get it
exactly right.

Adam