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

[Adam Barth <[e-mail]>]

On Tue, Aug 17, 2010 at 11:45 PM, Marsh Ray <[e-mail]> wrote:
> On 08/17/2010 11:21 PM, Adam Barth wrote:
>> Indeed.  We're not talking about DoS protection.
>
> I wasn't the one who brought it up.

Yeah, I should have pointed out earlier that it was off-topic.  You
replied before I got a chance to.

>> 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?

>From my perspective, WebSockets are the primary driver for NPN.
However, it's likely that not everyone agrees with me.  However,
complaining about WebSockets isn't appropriate for this forum.  Those
issues should be brought up in the HyBi working group.  In particular,
you seem to disagree with some of the basic design decisions as
captured in draft-ietf-hybi-websocket-requirements.  That working
group is going to design a protocol with those properties by one
mechanism or another.  If you'd rather that didn't happen, you should
really bring up those concerns in the proper forum.

> Are there other protocols that would benefit from this functionality?

Hopefully.  :)

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

I believe a TLS+NPN handshake is the best design for WebSockets.  As
that design involves a TLS extension, I've been asked to bring the
pieces that touch TLS to this working group for feedback about how
they interact with TLS as a whole.

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

Feel free to read the draft.

>> 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?

WebSockets.

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

I think your confusion might be stemming from confusing me with Adam
Langley.  Although we're both named Adam, we're are, in fact,
different people with different interests.  Adam Langley originally
design NPN for another use case.  However, the mechanism he design is
deliciously elegant and turns out to be exactly what WebSockets needs
to avoid cross-protocol attacks.  In fact, when he wrote
draft-agl-tls-nextprotoneg-00, no one had yet realized that NPN was
useful for WebSockets.  We only figured that out later.  I'll ask Adam
to update the draft with our current thinking on the topic.

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

No.  As you and others have pointed out, that's a fools errand.

>> 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.

Precisely.

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

Indeed.  That's because Adam didn't know it was useful for that when
he wrote the document.  Turns out, NPN sits at a very nice point in
the design space.  I suspect it will be useful for many things that we
currently are not aware of as well.

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

That might have been Adam's original motivation, much like HTTP's
original motivation was the transport of HTML document but we've
discovered that HTTP is useful for a great many other things, some of
which might be more important than transporting scientific papers
around CERN.

>> 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.

The only participant in that scenario that's breaking any rules is the
attacker.  I don't know about you, but I usually imagine that
attackers are willing to break whatever rules they choose.

> At what layer of the stack do you envision this being enforced?

By the browser, of course.

> Is the TLS library expected to detect and prevent this condition?

No.

> Is application layer
> code expected to supply and check for the correct protocol identifier with
> every handshake?

Yes.

> Where is this process described?

In the WebSocket specification.

> Are you proposing updating every piece of application software functioning
> as a TLS server or client?

No.  Don't be ridiculous.

> Or is it done somehow automagially?

Folks who don't wish to identify which protocol they intend to speak
after the TLS handshake can safely not use the extension.  Folks, such
as WebSockets, for which this information is critical to their
security model, will be required to use the extension by the
definition of the protocol.

>> 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.

This is how browser security works.  The browser sets the ground rules
for what the attacker can do by exposing or not exposing various APIs
to web sites.  In this case, the browser will expose the WebSocket
API, which permits the attacker (a malicious web site) to engage in
the WebSocket protocol via the user's browser.  I believe the piece
you're missing is the browser as the enforcer of security rules.
While I appreciate that you might not be used to thinking about
security in these terms, I can assure you that this design is quite
pedestrian in the browser world.

>> 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?

I didn't understand your question.

> What about or the other higher-level protocols that supposedly beenfit from
> this?

I haven't mentioned any other high-level protocols.

> Again, must they be updated to check it too?

No.  Because they don't participate in NPN, the counter party (either
the client or the server, depending on who we're worried about at the
moment) will notice that they're not using NPN and hence must not be
speaking WebSockets (as all the folks who speak WebSockets use NPN).
They can then safely terminate the connection without risk of
accidentally speaking WebSockets to a counter party who is not
speaking WebSockets.

>>> 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!

Thanks for your feedback.  This looks to be an area in which we can
improve the extension.

> 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.

Thanks for your feedback.  This looks to be an area in which we can
improve the extension.

>> Are you reading the same document I am?
>
> Is this right?
> http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00

Perhaps the problem is that our thinking has evolved a bit since
January.  I'll ask Adam to update the draft with our current thinking.

>> 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.

My apologies.  That text that reflects eight month old thinking.

>> 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.

Perhaps it's worth examining in more depth before forming an opinion about.

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

>From this working group, I'm interested in feedback about NPN.  To
understand what properties we'd like out of NPN, it's helpful to
understand WebSockets as context.  If you'd like to provide feedback
about WebSockets, kindly direct that feedback to the HyBi working
group.

> Does NPN have significant utility beyond WebSockets?

At the moment, I'm most interested in using NPN for WebSockets.  I
suspect we will find that it has utility beyond WebSockets in the
future, but I'm not interested in loading NPN up with lots of
complexity to address every imaginable use case.

> The subject line says NPN and that I-D doesn't mention WebSockets.

That's because WebSockets didn't exist in their current form when the
draft was written.

>>> 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.

I think by now you can predict my answer to this comment.  :)

>>> 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?

I'm saying that's a separate issue.  If you have a pressing need to
solve that problem, I'm sure we can design a very nice solution for
you.  Currently, that's not the problem I face.

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

Indeed.

[Snip a bunch of redundant text about multiplexing.]

>> 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?

As I've said before, to prevent cross-protocol vulnerabilities.

> 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.)

Currently there does not exist a mechanism to perform a handshake to
confirm what protocol is being spoken.  That is precisely the missing
piece that we need to achieve the security properties we want for
WebSockets.  What mechanism did you have in mind?  As far as I know,
NPN is the best.

> 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?

No.  I know of no other way to do it.  Do you have something else in
mind?  The best the HyBi working group can come up with (as from NPN)
is some extremely hacky protocol involving the MD5 of three different
nonces.

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

You're forgetting that the attacker, in this scenario, is a malicious
web site and so is limited to the network facilities provided by the
browser.  (Of course, we care about other sorts of attackers too, but
we have other security mechanisms to prevent them from causing harm.)

> Then why does the doc say:

See above.  The motivation in the draft is outdated.

>>> 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.

You might well.  However, the HyBi working group is going to continue
on the path of multiplexing WebSockets and HTTPS over port 443 without
or without NPN.  If you find that objectionable (which you appear to),
you should bring your objection to the HyBi working group.  In any
case, it's quite independent of NPN.

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

Yes.

> Who is this "we" you are referring to?

The HyBi working group.

> This is starting to feel a little creepy.

Why?  To solve a particular design problem, one IETF working group is
considering a design that makes use of technology designed by another
IETF working group.  It seems quite appropriate for that working group
to ask for advice from the experts in the other working group.

>>> 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?

In my opinion, that handshake is garbage (to use your term).  More
seriously, I believe we can achieve better security by using TLS+NPN
instead of the hacky nonce/MD5 handshake that "sorta" looks like plain
HTTP.

>>> 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.

Yes, but that's not what you were talking about.  I'm not interested
in discussing whether using TLS for some obscure feature of the web
platform will start a great movement to encrypting every byte on the
Internet.  If you're interested in discussing that topic, please start
a new thread.

> 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".

Brian Smith does not speak for me.  I speak for me.  Just because some
random person thinks NPN really useful for chopping vegetables doesn't
mean I'm giving you the run around when I say I'd rather use this
device to chop vegetables:

http://www.youtube.com/watch?v=rUbWjIKxrrs

> 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.

I apologize that the draft is out of date.  I should have asked Adam
to update the document before I emailed the list.

> Come on, what's going on here?

What's going on is precisely what I've been saying from the beginning.
 In particular, I'm interested in resolving this ticket in the HyBi
working group:

http://trac.tools.ietf.org/wg/hybi/trac/ticket/14

As requested by various folks, I'm bringing the NPN extension to this
working group to gather feedback on how the extension interacts with
TLS.

Kind regards,
Adam