Re: [hybi] Extensibility mechanisms?

[Greg Wilkins <[e-mail]>]

On 22 July 2010 14:40, Adam Barth <[e-mail]> wrote:

> The more I read on this list, the more I think that folks here don't
> understand the requirements on the protocol, especially the security
> requirements.  That's understandable if you haven't worked extensively
> with the browser security model.  Fortunately, Ian is an expert on
> these topics and has more time to reply to this list than I do.  I'll
> try to address some of the confusion in this email, but I might not be
> able to answer all the followup questions.
>

Adam,

I don't think there is any specific lack of understanding of protocol
requirements in this WG. However there may be some disagreement with what
those requirements are.

It is great that you respect Ian's opinion, but I'm afraid he has failed to
convince many in this WG of the need for some of the more esoterica
"features" in the -76 draft.

Take the security issue for example.  There was a concern that websocket
could be used in combination with an injectable server to spoof it to
generate a legal websocket handshake response (what good that would do
anybody I don't really know, but let's assume that it is evil and dangerous
and that the injectable server cannot be exploited in other ways).    In
response to that concern, this list pretty much agreed that we should
include a random token in the handshake that was generated after the URL had
been passed to the javascript websocket API.  Since this token would be
unpredictable, then it would be impossible for anybody to craft a URL that
would cause that token to be injected in a response. Problem solved.

But when Ian codified this general agreement in the specification, he
adorned it with several extra "features".  He split the random number up and
added a pseudo secure algorithm involving count spaces, taking away the
number you first thought of and divide by your grandmothers birthday.  This
is totally unnecessary complexity and confusion because the random token
would be generated after any client had the chance to inject the URL, so no
further protection is needed from injection.  It is another silly example of
being fixated on the exact bytes of a message rather than the semantics that
the message is carrying.

Ian further "enhanced" the solution by sending the random token, not in
headers as had been discussed, but in extra bytes that comply neither with
HTTP nor with websocket framing.  The motivation for these bytes is
apparently to fast fail if there in an intermediary that does not support
websocket.   However, among many other problems with this mechanism, it has
now been shown that this mechanism slow fails with an intermediary that
would support websocket if not for the extra bytes.

Fast fail is indeed a very desirable requirement (although not always
achievable).   Protection from injection is also a desirable requirement.
But there was no need to mix the solution to these two requirements into a
single solution (with extra pseudo security).  If Ian had simply added the
random token as a header as had been discussed and widely accepted, then we
would no longer be talking about it.

He could also have raised the fast fail requirement (ideally by proposing it
as an addition to the requirements document), and then we could be using the
considerable experience available in this WG (and elsewhere) to come up with
the best solution to that problem.

We will only make progress is we methodically break down requirements and
consider multiple solutions.   Intransigent insistence of the first
one-size-fits-all "solution" does not help at all.

regards