Re: [TLS] Request for review: Next Protocol Negotiation Extension

[Marsh Ray <[e-mail]>]

On 08/17/2010 11:49 AM, Adam Barth wrote:
>
> That's a pretty narrow view of TLS.  Certainly not everyone will want
> to use this extension.  In fact, I suspect it will only be used by the
> narrow subset of folks who are interested in defending against
> cross-protocol vulnerabilities.  However, that's one of the great
> benefits of modularity in protocol design: you can pick and choose the
> extensions that are appropriate for your use of the protocol.

Let's not forget that this proposal creates a new handshake message as well.

> The TCP protocol already has a similar extension point (i.e., ports).
> However, ports were not designed with cross-protocol vulnerabilities
> in mind and, unfortunately, are not sufficient security primitives.

Run protocols on their designated port. Don't overload port numbers. 
Don't allow unauthenticated connections to do anything significant (like 
send mail) on any port (source IP does not count as authentication). 
Don't allow web pages to initiate arbitrary connections.

> Believe me, I would much rather use TCP ports if they worked.

It's almost that they work too well to be trusted to a browser.

> We have an approach to defending against cross-protocol attacks at a
> higher layer of the stack, but it's extremely hacky.  Basically, you
> make the server do some esoteric calculation based on some nonces sent
> by the client.  The hope is that no existing server would do that
> esoteric calculation and, therefore, if the server gets the right
> answer, it must be speaking WebSockets.

I dunno, doesn't seem all that different from any other kind of handshake.

> It's hard to make a convincing security argument why that approach
> works.  It's more like a wing and a prayer.  NPN is the best approach
> I've seen for defending against cross-protocol attacks.  I believe
> using a TLS extension to solve this security problem is too good a
> design to ignore.

This is not without good precedent, SSH seems to do a fine job of 
multiplexing various services over its single port.

I liked the argument about "extending the origin model to do plain 
socket connections securely".

> On Tue, Aug 17, 2010 at 9:30 AM, Marsh Ray<[e-mail]>  wrote:
>> It also sounds like one could get 90% there just by doing session
>> resumption.

> We expect it to be very common for a web page to make a WebSocket
> connection to a different host.  For example, one important use case
> for WebSockets is chat-like functionality on a web page.  Facebook
> chat, as an example, operates on a separate host name than the main
> Facebook web site.  In those cases, we won't have a TLS session to
> resume.

Is it of consequence for the Facebook chat widget to take 150 ms to 
begin chatting?

So much so that it justifies additional complexity (i.e. attack surface) 
at the TLS layer?

Is there an example of a use for this protocol which is, in fact, highly 
latency-sensitive on the very first connection to the app server of the 
session?

Sorry if I'm sounding negative, that is not my intent. The answers may 
very well be 'yes' but I think the questions should be asked.

> These are issues for the HyBi working group.  I can tell you that
> browser vendors which to implement an interoperable WebSocket
> protocol.  I suspect you'll find it difficult to convince the HyBi
> working group on these points.

I'm not sure the IETF is the one to do the convincing for a TLS 
handshake modification, particularly if it could harm interoperability 
without a darn good reason.

To a large extent it seems the motivation here is to overlay another 
namespace of type opaque <0..255> for negotiating app layer protocols 
separate from the well-known port assignments thus bypassing the IANA 
and the control of firewalls and site admins.

>> (Why does WebSockets send garbage after a GET request?)
>
> That's part of the hacky non-TLS defense against cross-protocol
> attacks.

Just out of curiosity, why couldn't they send it in one of the custom 
headers? Or a POST?  I was under the impression that GET prohibited the 
inclusion of a document body.

Did the IANA understand the plan was to send gratuitously invalid HTTP 
when they recommended this be overloaded on TCP port 80?

For a group so concerned about protocol attacks, it sounds like they're 
intending to ship a fuzzer! (And one that can be pointed at your 
internal servers at that.)

I know WebSockets isn't on trial here, but it seems like one of the main 
justifications for NPN.

> The version that uses a TLS-based handshake doesn't have any
> of that garbage (to use your term).

Adam et al. let me say I really admire you guys' work.

It's really cool to have proposals to extend the web in new and 
interesting ways, addressing security from the beginning, and to squeeze 
out every last round trip and millisecond of latency.

But you guys are so prolific! I know I'm not the only one who feels a 
little overwhelmed at the three or four semi-overlapping proposals we've 
seen recently to extend TLS in minor and major ways. Some of these seem 
targeted at a relatively narrow deployment scenario (e.g., phones with 
GPS time) yet they suggest fundamental changes to the protocol from a 
security perspective.

Usually, the goal seems to be cutting down on latency at the cost of 
complexity (sometimes involving even TLS API layer changes). If a 
protocol change only helps in a relatively specific case, doesn't have 
multiple vendors jumping to implement it, and you could get 80% there 
with what we have already (e.g. session resumption) then it may not be a 
good bargain for the protocol as a whole.

Even if all these proposals were shown to be secure individually, and 
were all accepted, it could easily result an overall system which is not 
secure in combination. "Security is not composable" -Sergey Bratus

IMHO, the WG needs to be quite conservative about accepting extensions 
or other modifications to the handshake with potential security 
implications, however well-designed they may be. We could easily end up 
in a situation where nobody's ever tested certain combinations of 
extensions and endpoints interpret an ambiguous situation differently, 
with disastrous results. We could also end up in a state which is stable 
and secure, but we're unable to evolve the protocol much going forward 
because of some combinatorial explosion of interdependencies.

So forgive me if I sound negative, again, I really like the overall 
direction of this work. But I keep getting the feeling that at some 
point this much innovation is better off with a fresh design, rather 
than extending TLS far outside its original design envelope. I know new 
port numbers can limit acceptance, but maybe you could use a 
TLS-compatible client hello?

Alternatively, perhaps it would be possible to consolidate some of these 
ideas into fewer, more coherent, proposals?

Just a thought.

- Marsh