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

[Marsh Ray <[e-mail]>]

On 08/17/2010 11:21 PM, Adam Barth wrote:

> On Tue, Aug 17, 2010 at 5:14 PM, Marsh Ray<[e-mail]>  wrote:

>> Port 443 isn't magic. It's just as DoS-able as others, if not more so.
>> Multiplexing multiple protocols on top of port 443 might even limit your
>> options in the event of an actual DoS (possibly inadvertent).
>
> Indeed.  We're not talking about DoS protection.

I wasn't the one who brought it up.

>> Oh and I forgot: disable NTLM (my latest crusade).
>> http://extendedsubset.com/?p=36
>
> I don't understand how this relates to the topic at hand.

Cross protocol attack.

>> Interesting, I had heard of that. Link?
>
> This is a well-established fact.

Nice, I'll have to use that one sometime. :-)

> I don't think this is the proper forum to debate the performance
> requirements of the WebSocket protocol.  Suffice it to say that the
> folks who want to use the protocol want it to be fast.  That doesn't
> sound unreasonable to me.

So, is NPN about WebSockets or not? Is the WebSocket use case an 
important driver for the requirements of NPN?

Are there other protocols that would benefit from this functionality?

If not, why is there so much discussion about WebSockets?

> With or without this extension, the current plan in the HyBi working
> group is to multiplex WebSockets with HTTPS over port 443.  If you
> think that's a bad idea, you'll need take that up with the HyBi
> working group.

Whatever.

I'm just trying to find out what
draft-agl-tls-nextprotoneg-00 is acutally proposing.

> The purpose of this TLS extension is to improve the
> security of the protocol, not to enable multiplexing.

So the purpose of NPN is to improve security of "the protocol". Which 
protocol is that again?

It's not a purpose of NPN to enable multiplexing?

 From http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00#page-5
> Rather than forcing systems
>    administrators to use different IP addresses for every service,
>    negotiation allows multiple services to exist with the same IP
>    address.

> That's not the goal.  Please refer to my earlier emails for a
> description of the security properties we seek to obtain with this
> extension.

OK, resisting traffic analysis is not a goal of NPN.

> Indeed.  That's because this is the problem we seek to solve with this
> extension.

OK, the NPN proposal attempts to mitigate cross protocol attacks.

But draft-agl-tls-nextprotoneg-00 doesn't seem to say anything about 
cross-protocol attacks, it doesn't mention attacks of any sort.

It says:
> Abstract
>
>    This document describes a Transport Layer Security (TLS) extension
>    for application layer protocol negotiation.  This allows the
>    application layer to negotiate which protocol should be performed
>    over the secure connection in a manner which avoids additional round
>    trips and which is independent of the application layer protocols.

Sounds to me like the I-D is saying it's a protocol-agnostic 
multiplexing scheme which can avoid round trips.

> In the protocol
> we're proposing, it's unreasonable (read: a violation of the
> specification) to try to talk SMTP over a TLS tunnel after agreeing
> that the next protocol is WebSockets.

I'm sure it's a violation of many specifications to use an HTTP POST to 
send spam.

At what layer of the stack do you envision this being enforced? Is the 
TLS library expected to detect and prevent this condition? Is 
application layer code expected to supply and check for the correct 
protocol identifier with every handshake? Where is this process described?

Are you proposing updating every piece of application software 
functioning as a TLS server or client? Or is it done somehow automagially?

>  The extension adds the
> semantics that are present only heuristically currently, letting us
> gain a strong security property.

I see something (but what?) being stated explicitly in the protocol, 
which could be useful. But I don't see the mechanism which is going to 
guarantee this as a strong property.

> Indeed.  I believe NPN is the right way to do it.  It is treated as a
> security-critical component by the WebSocket protocol.

Oh. Is it intended then to simply pass these opaque elements (like 
selected_protocol) to WebSockets to check it for validity?

What about or the other higher-level protocols that supposedly beenfit 
from this? Again, must they be updated to check it too?

>> Rather than opaque<0..255>  we need defined encoded values. If not, as
>> someone suggested, using existing port assignments, then perhaps a string.
>> These values should be assigned by IANA. There should be a convention for
>> private-use and experimental identifiers. The valid characters, whitespace
>> rules, and the exact method of string comparison must be defined.
>
> I believe that's how the extension works.

I believe in the I-D, and it says:

 >    struct {
 >      opaque selected_protocol<0..255>;
 >      opaque padding<0..255>;
 >    } NextProtocol;

There's no description of the contents of the selected_protocol and 
padding elements!

http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00
> 5.  IANA Considerations
>
>    This document requires IANA to update its registry of TLS extensions
>    to assign an entry, referred herein as "next_protocol_negotiation".
>
>    This document also requires IANA to update its registry of TLS
>    handshake types to assign an entry, referred herein as
>    "next_protocol".

I don't see anything describing how the valid protocol identifiers are 
to be assigned.

>> Use with underlying transports other than TCP should be defined i.e., do the
>> rules still apply if you run TLS over raw serial or stdin/stdout?
>> What about DTLS?
>
> Marsh, you seem confused.

No kidding!

> Are you reading the same document I am?

Is this right?
http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00

> Where's the dependence on TCP?

http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00
>    Firstly, for various reasons, different application layer protocols
>    are increasingly being carried over TLS using a small set of TCP port
>    numbers, most often port 443.

It's not a protocol dependence on TCP per se, but any systematic 
protocol naming scheme is likely to run into the TCP vs UDP name 
overloading.

Perhaps I was jumping the gun to assume there was a systematic protocol 
naming scheme being discussed here.

>> Is there ever a case for more than one instance of a protocol on an address?
>> If you want to start another http server, say for app development, is there
>> an equivalent to "port 8080"? If so, wouldn't browsers and other client apps
>> need a way to specify it in the url?
>
> This is present in WebSockets.  It is, in fact, carried in the URL, as
> you suggest.  I feel like you and I are in violent agreement.  All the
> things you're asking for are already the case.

I feel like I'm violently confused. Assume that I haven't looked into 
WebSockets beyond skimming the Wikipedia artice.

Just what are we talking about: the proposed NPN TLS extension, or 
WebSockets?

Does NPN have significant utility beyond WebSockets? The subject line 
says NPN and that I-D doesn't mention WebSockets.

>> Are any security properties associated with some names and not others? Is
>> there an equivalent to privileged "low numbered ports"? Should OS
>> permissions be involved in who can start a new server?
>
> No.  The semantics of the protocol are defined by the protocols themselves.

By cramming everything onto port 443 I expect people will bring a lot of 
expectations from OS-land about how such a resource should be shared and 
access authorized.

>> How is client cert auth to be performed?
>
> There's no interaction between NPN and client auth.  It's performed in
> precisely the way it is today.
>> Is it a problem that it's not configurable per-protocol?
>
> Not that I'm aware of.

You're saying it's not reasonable for someone to negotiate the use of 
client certs (or not) on a per-protocol basis?

Let me guess: that capability is not needed for WebSockets.

>> Note that MS Windows has had, for many years now, an in-kernel https server
>> which by default takes port 443. They support multiple protocols for RPC,
>> remote access, and of course web serving all on the same port. I believe
>> they support PPTP VPNs on 443 with a similar mechanism. What can we learn
>> from that experience which might help in this design?
>> (did I mention that everyone should disable NTLM?)
>
> I'm not familiar with this design.

It works pretty seamlessly.

Here's a VPN using it:
http://technet.microsoft.com/en-us/magazine/2007.06.cableguy.aspx

Search for "443" on this page:
http://support.microsoft.com/kb/832017

> You're seem unduly concerned with
> multiplexing.  That's not the essential feature here.

Again, quoting from
http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00#page-5
"negotiation allows multiple services to exist with the same IP address."

Regardless, if it does negotiation, it seems like a pretty important 
thing to get right. It's probably what most admins are going to 
associate with configuring support for this extension.

> The essential
> feature is agreement about what protocol we're going to speak over the
> encrypted tunnel.  WebSockets would want NPN even if it were always
> run on a dedicated port.

Why?

Established methods exist to find a service on an assigned port, make a 
handshake to confirm what protocol is being spoken, and perform a decent 
authentication (unless anonymous connections are truly desired.)

Why does this now need a new TLS extension and even a new handshake 
message? Is it just that you're expecting to be using TLS anyway and can 
maybe save a round trip that way?

If an attacker can point to a vulnerable server port with any handshake, 
he can blast it with a TLS client hello handshake, too.

>> Insecure (without RFC 5746) renegotiation can now easily be a cross-protocol
>> attack. Should this spec forbid it?
>
> Perhaps.  I haven't studied this question in detail.  Note that the
> answer is non-obvious because the attacks that RFC 5746 is meant to
> address occur in a different threat model than the one we're concerned
> with here.

I see.

>> Could it be made an option to get the server's list of protocols while under
>> a basic encrypted session, providing that confidentiality like for client
>> certificates?
>
> In the scenarios we're interested in, the client is initiating a
> particular protocol.  There's no need to discover what other protocols
> the server might speak.

Then why does the doc say:
>    The "extension_data" field in a "ServerHello" and the "NextProtocol"
>    message contain opaque bytes to be used by the application layer to
>    negotiate the application layer protocol.  The format of this data is
>    not specified in this draft.

And yet:
> 4.  Security considerations
>
>    The server's list of supported protocols is still advertised in the
>    clear with this extension.  This may be undesirable for certain

So is the server defined to send a list of its supported protocols in 
the server hello extension, or not? If so, shouldn't it be done in at 
least a defined way? If not, just what the heck is it sending?

>> Should the client's SNI be allowed to or prohibited from influencing the
>> server's list of supported protocols?
>
> The server is permitted to refuse any connection it doesn't like for
> any reason.  The phase of the moon can influence whether the server
> opts to complete the handshake.

OK.

> This paragraph seems like a non-sequitur.

You cut out the part I was replying to.

>> My concern is that at the end of the day we end up with no great victory in
>> transport neutrality. Instead we get might just get another layer of
>> redundant indirection, more protocol complexity, and worst of all,
>> TLS-intercepting MitM proxies sprouting all over the net like dandelions.
>
> I'd encourage you to bring this point of view to the HyBi working
> group.  It, however, is unrelated to whether we use the NPN extension.

I think I have a valid concern here which relates directly to the 
evolution of TLS.

But I still don't get it. Was this extension to TLS proposed just for 
the benefit of this HyBi working group?

Who is this "we" you are referring to?

This is starting to feel a little creepy.

>   Currently, that working group takes the opposite viewpoint as a
> requirement of the protocol, regardless of whether the protocol
> involves NPN.

I don't understand.

>> But if it requires a software (if not hardware) upgrade to support the
>> extension, wouldn't that just encourage deployments to use plain HTTP?
>
> Plain HTTP does not support the use cases WebSockets supports.  If it
> did, there would be no need to invest in WebSockets.

I thought WebSockets could begin a handshake looking sorta like plain HTTP?

>>> Then their end-users can enjoy improved privacy and better authentication
>>> of servers when otherwise it may never be made available for them. I think
>>> this
>>> could result in a snowball effect that would make encrypted and
>>> server-authenticated communication much more common or even eventually
>>> ubiquitous. I think the chance that this happening is reason enough to
>>> integrate this mechanism into TLS.
>>
>> As appealing as the idea sounds to me, "encouraging" a transition before
>> people would choose it on their own is likely to lead to a lot more
>> self-signed certs out on the web.
>
> Be that as it may, it's irrelevant to topic currently under discussion.

Last I checked the Subject line was:

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

I think the question of what this thing is and whether or not it adds 
general utility to TLS (or is part of some unspecified grand plan) is 
entirely relevant.

I feel like I'm totally getting the runaround here.

On person says "it is this" another says "it is not that, it is this".

The I-D talks about a round trip, protocol multiplexing, and something 
about HTTP pipelining. It says there will be a new extension and a new 
handshake message, yet every single octet they carry are opaque and the 
document claims they are out of scope.

Come on, what's going on here?

- Marsh