Re: [hybi] Extensibility mechanisms?

[Adam Barth <[e-mail]>]

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.

On Wed, Jul 21, 2010 at 9:14 PM, Scott Ferguson <[e-mail]> wrote:
> Adam Barth wrote:
>> I don't think you understand how cross-protocol attacks work, and I'm
>> not that interested in educating you about them.  HTTP POST requests
>> are also very poorly designed in this way and have been the cause of a
>> number of cross-protocol attacks, most recently against IRC.
>
> Well, we have two conflicting desires that need to be resolved:
>
>  1) To make WebSockets initial latency no worse than HTTP. (If I understand
> correctly, this is the issue raised by Jamie and also Greg.)
>
>  2) cross-site scripting

There is surprisingly little interaction between cross-site script and
the security requirements on WebSockets.  However, there is a large
interaction between the security requirements on WebSockets, the
browser's same-origin policy, and cross-protocol vulnerability.
Please note that cross-protocol vulnerabilities have nothing to do
with cross-site scripting.

> I see only 3 possible resolutions:
>
>  a) That 1 & 2 are irreconcilable and WebSocket performance must be worse
> than HTTP/comet because its security must be better than HTTP.

I don't understand what this means.  How could latency requirements
for a network protocol be irreconcilable with cross-site scripting?
The two operate at completely different layers of abstraction.

>  b) WebSocket performance must be as good as HTTP/comet as long as its
> security is no worse than HTTP.

What does it mean for security to be no worse than HTTP?  When
thinking about security, it's important to consider what security
goals you're trying to achieve in the presence of what sort of
adversary.  It's far from a one dimensional quantity that can be
"better" or "worse" than another.  Your statement is basically
nonsensical.

>  c)  Both 1 & 2 are resolvable and the solution is XXX.

It's clear to me that we can achieve both performance and security.
We've seen several proposals that achieve that.  Of course, those
aren't the only requirements we're aiming to meet...

> If (a) or (b) are selected, it should be a conscious decision, not chosen by
> default. I assume you're in camp (a)?

What's the difference between choosing something by default versus a
conscience choice?  From my statements above, I think you'd put me in
camp (c).

> If you believe (c), than it seems to me you either need to propose an XXX or
> suggest fixes to a flawed XXX proposal to make it work.

I've already did so back in May:

http://www.ietf.org/mail-archive/web/hybi/current/msg01948.html

This is different from the protocol in the current working draft
because it requires TLS.  I think TLS+NPN is a much better design than
the current HTTP-ish design, for the reasons outlined in that email.
The main (only?) disadvantage is that it requires amateur server
implementations to use a TLS library.

> The current official draft proposes (a), but it seemed to me that the group
> is divided on the issue, and I made an attempt at an XXX. Perhaps I
> misunderstood, everyone's in camp (a).

It's fine to propose designs as food for thought, but claiming that
you've addressed all the requirements when you haven't even met the
basic security requirements is a bit brash.

> (I suppose there might be a (d): browser clients are restricted to (a) but
> non-browser clients can use (b). But that would probably be too messy for a
> spec.)

I don't care what non-browser clients do.  I'm here to help design a
protocol for use by browsers.

Adam