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

From: Adam Barth <[email-masked]>
Date: Mon, 16 Aug 2010 10:07:49 -0700

TLS experts,

As some of you may be aware, the HyBi working group is considering use
a TLS extension has part of the WebSockets protocol [1].  I believe
the extension has been mentioned on this list before, but as there is
now renewed interested in its use, now might be a good time for this
working group to look over the extension and provide feedback.

The extension, called Next Protocol Negotiation, adds information to
the TLS handshake to let the client and server agree on which protocol
they will speak over the encrypted tunnel once the handshake
completes.  In some sense, this extension is to TLS what ports are to
TCP: it allows multiplexing a number of protocols over a single
listening endpoint (in the case of TLS, a TCP port, in the case of
TCP, an IP address).

The HyBi working group is interested in Next Protocol Negotiation
because it has two properties:

1) It allows servers to multiplex HTTPS and WebSockets over the same
listening port (typically 443).
2) After completing the TLS handshake (with the extension) both
parties are guaranteed that the other party intends to speak
WebSockets over the encrypted tunnel.  (This property is important to
avoid cross-protocol vulnerabilities, which I can elaborate on if
you're not familiar with that class of vulnerability.)

The current Internet-Draft is located here:

http://tools.ietf.org/html/draft-agl-tls-nextprotoneg

I look forward to receiving your feedback.

Kind regards,
Adam

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Aug 2010 10:18:49 -0700

[Speaking as chair; I'll have some technical comments later.]

The current draft of NGN (draft-agl-tls-nextprotoneg-00) defines two
new code points (Section 5):

- A new TLS extension type.
- A new TLS handshake type.

The TLS standard (RFC 5246) defines the rules for the assignment of code
points in these
ranges. Extension types may be defined by "IETF Consensus" (this requires an
IETF LC).
Handshake types must be defined by "Standards Action" (this means a
standards
track RFC). This means that as a practical matter NGN as currently
constituted will
need to go through the TLS WG in order to reserve the code point through the
IETF
process. (To state the obvious, vendors can obviously grab a code point and
say
"that's NPN", but I'm assuming the intent is to actually follow the IETF
standards process
here.)

The status of NPN is that a draft exists, but there hasn't been a huge
amount of discussion
on the list, it has never been presented at a meeting, isn't a WG item, and
the chairs
have never been asked to take it on as such.

-Ekr

On Mon, Aug 16, 2010 at 10:07 AM, Adam Barth <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Adam Langley <[email-masked]>
Date: Mon, 16 Aug 2010 13:34:30 -0400

> have never been asked to take it on as such.

Previously, I didn't want to push the standards process forward before
we had interoperable implementions and some real world testing. Since
the first posting of the NPN draft we now have NSS support[1] (out of
tree) and OpenSSL support (in their CVS). Both have been heavily
tested.

With the added interest of WebSockets, I would now like to request
that the chairs consider this draft as a possible WG item.

[1] http://src.chromium.org/viewvc/chrome/trunk/src/net/third_party/nss/patches/nextproto.patch?view=markup

AGL

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 16 Aug 2010 10:42:59 -0700

One problem is that the server is not made aware of the next protocol
until just before the Finished messages are exchanged.  By delaying
this information, the server can not use the protocol as part of its
certificate selection process.

I understand the desire to keep this information private, but it comes
with a cost.  If the server is handling many protocols and desires to
use different certificates for each because of different security
requirements such as lists of supported cipher suites per protocol, or
maybe they are hosting multiple virtual hosts and need to select the
proper certificate from a particular customer.

If the response to this is "use SNI" then you just leaked the information
you are trying to hide by delaying the next protocol until after CCS.

Mike

---

From: Adam Langley <[email-masked]>
Date: Mon, 16 Aug 2010 14:02:04 -0400

> proper certificate from a particular customer.

I agree that it's a trade off. The design, as is, was picked because
the use cases considered were either ambivalent on this point or
favoured the privacy side (i.e. Tor).

Following a more traditional "client presents a list, server picks" is
a reasonable solution, and one that we could accept if opinion was
overwhelming on the matter. But this draft was partly born as a result
of the decay of the end-of-end principal which has rendered TCP port
numbers an ineffective solution. Thus this draft made efforts to be
more future-proof.

AGL

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 16 Aug 2010 13:30:48 -0500

> One problem is that the server is not made aware of the next protocol
until just
> before the Finished messages are exchanged. 

Wouldn't it actually be better to put the next protocol message *after* the
Finished message so that it can be protected with a HMAC instead of a HMAC
of a PRF'd hash?

> By delaying this information, the server cannot use the protocol as part
of its
> certificate selection process. I understand the desire to keep this
information
> private, but it comes with a cost. If the server is handling many
protocols and
> desires to use different certificates for each because of different
security
> requirements such as lists of supported cipher suites per protocol, or
maybe
> they are hosting multiple virtual hosts and need to select the proper
> certificate from a particular customer.
>
you are
> trying to hide by delaying the next protocol until after CCS.

SNI was created because the certificate contains the hostname, and the
server needs to choose the certificate based on the hostname. Since the
certificate doesn't contain the protocol, the server doesn't need to choose
the certificate based on the protocol in use. Choosing the cipher suite
based on the protocol doesn't seem very useful and doesn't fit with the TLS
design; the server is supposed to choose the best cipher suite that both
sides support. Also, current implementations already provide support for
switching the cipher suite based on information that they receive after CCS
via renegotiation. For example, Apache will start a renegotiation if the
request URL maps to a resource that has been (mis)configured to use a cipher
suite different than the default for the server.

Cheers,
Brian

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 16 Aug 2010 11:54:16 -0700

> the certificate based on the protocol in use.

It appears you are thinking just in terms of HTTP.  What I'm thinking about
is multiplexing other protocols such as SMTP and IMAP using this extension.
Your SMTP server would likely have a different certificate than your web
server, so the TLS layer would need to know which server (SMTP vs. HTTP) is
being contacted in order to use the correct certificate.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Mon, 16 Aug 2010 14:25:17 -0500

On 08/16/2010 01:02 PM, Adam Langley wrote:
> But this draft was partly born as a result

I am concerned by this proposal. Not that it's technically bad somehow 
but that it seems to be screaming and shaking its fist at the law of 
unintended consequences.

So let me just put these ideas out for discussion:

1. There are already plenty of options available ("VPNs") for tunneling 
arbitrary ports, IPs, even whole netblocks, through TLS or SSH. Perhaps 
these are too heavyweight of a solution in some cases, but nevertheless 
they are commonly used so we know they are options if the demand is great.

2. We already have a decent mechanism for supporting multiple protocols 
on a single IP address, even with TLS. It's "port numbers" doing exactly 
what they were designed to do.

The reason that "different application layer protocols are increasingly 
being carried over TLS using a small set of TCP port numbers, most often 
port 443" is due to the conscious decision of administrators and how 
they choose to configure their firewalls. They really do want to block 
all those other protocols! Today they can do so by selectively blocking, 
intercepting, and/or monitoring the ports they are assigned to.

But a lot of the stuff (standardized or not) running over 443 today is 
doing so just to get around the firewall! This degrades the ability of 
the admin to manage his network.

This is in fact a problem, not a feature that should be officially 
blessed with standardization in the form of a TLS extension.

If network admins are no longer able to effectively manage their traffic 
because it's all being tunneled through TLS on port 443, let's try to 
predict what the effect will be: Of course admins will continue to 
require the ability of the firewall to manage protocols, so they will 
have to inspect deeply the contents of port 443 traffic. This means 
clients will be forced to install trusted root CA certs from the 
inspecting firewall in order to make outbound connections. Of course 
these certs will remain trusted for connections from other networks as 
well. It means these CA private keys are not managed by audited 
processes in vaults underground, they get stored and used on 
internet-facing boxes where they are vulnerable to "unauthorized use". 
We all know they'll eventually be sold on Ebay without an effective 
revocation process. Of course, these root certs will be "automatically 
deployed", meaning browser users will be trained to accept new CA certs 
from time to time (yes, a hotel gave me a bogus cert for an unrelated 
website just a few days ago).

What if SMTP is standardized over this mechanism? What will ISPs which 
now block port 25 do to limit spam? Is this facility only appropriate 
for protocols which should not need blocking? Will those decisions be 
haphazardly decided?

Technical benefits aside, I believe that to the extent this proposal 
replaces the established port assignment mechanism it undermines some 
long established "interface contracts" of the net's design. If the goal 
is to some degree to usurp the admin's ability to control his traffic, 
the result will probably benefit no one.

As you guys know, I'm happy to be convinced, but think it could be a 
potentially significant change to some fundamental stuff which deserves 
due consideration.

- Marsh

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 16 Aug 2010 21:29:43 +0200

Hi,

If, according to Adam Barth "in some sense, this extension is to
TLS what ports are to TCP: it allows multiplexing a number of protocols 
over a single
listening endpoint (in the case of TLS, a TCP port, in the case of
  TCP, an IP address),"

why not using the IANA protocol port registry and and the integers
defined there?

Or, more general, an option would be a URI/URN although
combining several information into one textual representation
might not be a nice choice.

All assumed that these information can be transmitted in clear.

/PS

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 16 Aug 2010 14:32:48 -0500

Michael D'Errico wrote:
> server needs to choose the certificate based on the hostname. Since the  >
> certificate doesn't contain the protocol, the server doesn't need to
choose  >
> It appears you are thinking just in terms of HTTP.  What I'm thinking
about is
> multiplexing other protocols such as SMTP and IMAP using this extension.
server,
> so the TLS layer would need to know which server (SMTP vs. HTTP) is being
> contacted in order to use the correct certificate.

I was thinking of multiplexing SMTP, IMAP, HTTP, and DNS on the same port of
the same server. One of the purposes of doing so is to get around
unreasonable (mobile) ISP/government restrictions on IMAP and SMTP. But,
that is the exact scenario, you don't want to leak information about which
protocol is in use too easily--either in the TLS handshake itself, or in the
certificates sent during the handshake. Instead, you want to force the
ISP/government to do stateful timing analysis of the application_data
messages that go back and forth, because that is probably impractical to do
in real time on a large scale for reasonable amounts of money.

Regards,
Brian

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 16 Aug 2010 21:37:46 +0200

> working group to look over the extension and provide feedback.

Without getting on the details, why do that on the TLS protocol? This
looks like something to be done on the application protocol.

regards,
Nikos

---

From: Adam Langley <[email-masked]>
Date: Mon, 16 Aug 2010 15:43:03 -0400

On Mon, Aug 16, 2010 at 3:25 PM, Marsh Ray <[email-masked]> wrote:
> But a lot of the stuff (standardized or not) running over 443 today is doing
> so just to get around the firewall! This degrades the ability of the admin
> to manage his network.

>From the purely technical standpoint, TCP port numbers have two
significant drawbacks that NPN addresses:

1) When the network wishes to express policy (ignoring any arguments
about the legitimacy of such), it often does so by dropping SYN
packets. Thus one cannot reasonably query and adapt to a local policy
because waiting for a TCP timeout is unacceptable.

2) A similar issue exists with the end server: if the client wishes to
connect to one of n ports, the latency of trying a connection and
getting a RST back (assuming the RST even comes) is unacceptable.

(In both cases 'unacceptable' is based on the requirements of
interactive programs, i.e. browsers.)

I'm going to omit a response to your other objections because I fear
this isn't the forum to argue over the end-to-end principal.

AGL

---

From: Adam Langley <[email-masked]>
Date: Mon, 16 Aug 2010 15:47:32 -0400

> looks like something to be done on the application protocol.

Our main reason is latency: we cannot afford a round trip.

Our secondary reason is that it might not be transparent to proxies.
For an application-level protocol handshake over HTTP, this is a major
concern. With HTTPS, it's much less so. So we are spending a
round-trip to establish a TLS connection (with False Start, it's only
one) and hoping to get it back in the future with Snap Start.

AGL

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 16 Aug 2010 15:07:26 -0500

Marsh Ray wrote:
> This means clients will be forced to install trusted root CA certs from
> the inspecting firewall in order to make outbound connections. 

This is inevitable even without this extension, and it is in fact already
happening.

> What if SMTP is standardized over this mechanism? What will ISPs which now
> block port 25 do to limit spam? Is this facility only appropriate for
protocols
> which should not need blocking? Will those decisions be haphazardly
decided?

You can already provide SMTP over TLS over port 443. I remember seeing email
hosting providers providing this option when I was shopping for a host; they
just didn't have a HTTPS server on port 443. In fact, it is only accidental
that SMTP(S), IMAP(S), and HTTP(S) cannot be multiplexed over port 443 now;
if SMTP and IMAP were client-speaks-first protocols then it would be
trivial.

> Technical benefits aside, I believe that to the extent this proposal
replaces the
> established port assignment mechanism it undermines some long established
> "interface contracts" of the net's design. If the goal is to some degree
to usurp
> the admin's ability to control his traffic, the result will probably
benefit no one.

You can make the same argument against HTTPS-based email protocols. If the
network administrator needs to block email from computers it cannot control,
then it needs to decrypt and inspect all traffic, regardless of port or
protocol.

If network administrators effectively blocks SMTP and IMAP, HTTPS-based
protocols will become the new way to send/receive email.

Cheers,
Brian

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 16 Aug 2010 15:08:17 -0500

Adam Barth wrote:
> As some of you may be aware, the HyBi working group is considering use a
TLS
> extension has part of the WebSockets protocol [1].  I believe the
extension has
> been mentioned on this list before, but as there is now renewed interested
in its
> use, now might be a good time for this working group to look over the
extension
> and provide feedback.

The current draft seems to be written without consideration of snap start.
In particular, it says that the protocol negotiation is free because it
happens during first round-trip, which is unavoidable, whereas snap start
avoids that round-trip.

Also, I don't understand the prohibition against renegotiations including
the extension. The server cannot enable protocols based on the identity of
the client without requiring renegotiation client hellos to include this
extension.

Because of those two issues, I think it would be better for the list of
protocols supported by the server to become session-persistent attribute
while the current protocol in use should be a per-handshake attribute of the
connection.

The description of HTTP pipelining doesn't match RFC 2616. A client may send
multiple pipelined requests immediately (optimistically assuming the server
supports the feature), but should be prepared for the server to close the
connection after the first response. I guess this is more of a
theory-vs-practice issue, but even the practical use is quite nuanced. For
example, at least at one point in time, Amazon Web Services supported
pipelining and persistent connections, but it had a small upper limit (10?)
on the number of requests that could be issued on the same connection.
Consequently, it seems unlikely that this extension will be able to handle
all the practical aspects of HTTP pipelining interoperability in the way it
intends, without extensions also to HTTP; with such HTTP extensions, you
probably wouldn't need the next protocol extension for HTTP pipelining. It
will actually probably create headaches when the server has configured its
TLS implementation to promise "I support HTTP pipelining really well" but
the implementation doesn't live up to that promise.

Regards,
Brian

---

From: Adam Langley <[email-masked]>
Date: Mon, 16 Aug 2010 16:30:24 -0400

> happens during first round-trip, which is unavoidable, whereas snap start

The drafts are written independently although they are compatible. A
Snap Started NPN handshake involves the client presenting the NPN
extension, predicting the server's NPN reply and embedding a
NextProtocol message in it's ClientHello.

> the client without requiring renegotiation client hellos to include this

This was a simplification based on the assumption that the application
level wouldn't wish to switch protocols during a connection. If you
have a use-case which does need this, then I'd be happy to change the
current draft.

> connection after the first response.

You are correct; I was mistaken in my understanding of the RFC. I'll
remove the existing paragraph and will probably replace it with a
motivation deriving from WebSockets as that's less hand-wavy.

AGL

---

From: Adam Barth <[email-masked]>
Date: Mon, 16 Aug 2010 17:29:52 -0700

Replies inline (combined into one message to avoid spamming the list
with infinite replies).

On Mon, Aug 16, 2010 at 11:30 AM, Brian Smith <[email-masked]> wrote:
> Michael D'Errico wrote:
>> One problem is that the server is not made aware of the next protocol until just

I believe that would be fine too.  I don't think it matters that much, however.

> suite different than the default for the server.

Indeed.

On Mon, Aug 16, 2010 at 11:54 AM, Michael D'Errico <[email-masked]> wrote:
>> choose the certificate based on the protocol in use.
>

Why should the server's certificate vary depending on what the next
protocol is?  Your colleague Brian Smith appears to hold the opposite
belief.  Keep in mind that TLS extensions are cheap.  If that need
arises in the future, we design another next-protocol negotiation
extension to meet that need.

As various folks are fond of saying "you ain't gonna need it," which
roughly translates as (as I understand it) "you should design for the
problems you have and worry about future problems in the future."

On Mon, Aug 16, 2010 at 12:25 PM, Marsh Ray <[email-masked]> wrote:
> I am concerned by this proposal. Not that it's technically bad somehow but
> that it seems to be screaming and shaking its fist at the law of unintended
> consequences.

It's hard for me to address your non-technical concerns.  The use of
NPN for WebSockets is not in any way a fist shaking reaction to
anything.  It's a technical solution to the following technical
problem:

1) The client needs to be convinced that the server wishes to speak
the WebSocket protocol.

2) The server needs to be convinced that the client wishes to speak
the WebSocket protocol.

If either party cannot be convinced of that fact, then we leave
ourselves open to cross-protocol attacks, which is unacceptable in the
deployment scenarios for WebSockets.

> these are too heavyweight of a solution in some cases, but nevertheless they
> are commonly used so we know they are options if the demand is great.

For WebSockets, we're not interested in tunneling arbitrary ports.
We're interested in establishing the security property above, which is
the security property TLS+NPN gives us.

> 2. We already have a decent mechanism for supporting multiple protocols on a
> single IP address, even with TLS. It's "port numbers" doing exactly what
> they were designed to do.

Port numbers do not achieve the security property above.  For example,
suppose we choose port 39426 as the designated port for WebSocket
connections.  There's no guarantee that a server won't have a SMTP
server listening on port 39426.  If the client (in the typical
WebSocket deployment scenario, this means a browser) speaks WebSockets
to an SMTP server, we have a security problem, namely a malicious web
site you visit might be able to send spam via your computer and that
server.

> port 443" is due to the conscious decision of administrators and how they
> choose to configure their firewalls. They really do want to block all those
> other protocols! Today they can do so by selectively blocking, intercepting,
> and/or monitoring the ports they are assigned to.

While that might or might not be true, it's not relevant to
establishing the security property we seek to establish.

[trim]

> What if SMTP is standardized over this mechanism?

That would be great for the security of the web because we wouldn't
have to worry about HTTP POST requests being sent to SMTP servers and
generating spam.  We do have to worry about that today, and our
solutions are quite hacky (essentially port blacklisting) because SMTP
(even SMTP-over-TLS) doesn't use NPN.

> What will ISPs which now block port 25 do to limit spam?

What do these ISPs do today for all the folks that run SMTP servers
over TLS?  Somehow the world has failed to come to an end.

> Is this facility only appropriate for protocols which should not need
> blocking? Will those decisions be haphazardly decided?

That seems like an argument against using end-to-end encryption in
general.  Whether you want to use end-to-end encryption is a different
problem from whether you want the two participants involved in the
communication to agree about which protocol they're speaking.

> replaces the established port assignment mechanism it undermines some long
> established "interface contracts" of the net's design. If the goal is to
> some degree to usurp the admin's ability to control his traffic, the result
> will probably benefit no one.

That's not the goal, as discussed above.

> potentially significant change to some fundamental stuff which deserves due
> consideration.

I think you're overestimating the impact of this proposal.  We're not
intending to replace TCP ports, which work quite well for their
intended uses.  We're interested in solving a particular security
problem with WebSockets.  We could make a WebSocket-specific TLS
extension to address our narrow use case, but the mechanism seems
useful in general, hence the proposal for a more general mechanism.

On Mon, Aug 16, 2010 at 12:29 PM, Peter Sylvester
<[email-masked]> wrote:
> TLS what ports are to TCP: it allows multiplexing a number of protocols over
> a single

As a wrote in my response to Marsh Ray, that doesn't solve the problem
of convincing the client that the server intends to speak WebSockets.
Just because a server is listening on a particular port does not mean
that it intends to speak the protocol assigned to that port by IANA.
Similar, from the server's perspective, just because a client connects
to a specific port, that doesn't mean the client intends to speak the
protocol registered to that port by IANA.

Continuing the earlier example (this time from the server's
perspective), suppose we register port 39426 for WebSockets.  Now,
suppose a client connects to port 39426 and sends some bytes.  Can
server assume the client intends to speak WebSockets?  Unfortunately,
no.  The client might well be sending an HTTP POST to port 39426, for
example.

> might not be a nice choice.

Where would we put the URI/URN?  I don't understand your proposal.

> All assumed that these information can be transmitted in clear.

Whether the information is encrypted is not what's at issue here.
What's at issue is that the client and server effect a handshake
protocol and agree which protocol they'd like to speak next.

> looks like something to be done on the application protocol.

Honestly, because web browsers have been spamming TLS to every port on
the Internet for over a decade, so we have a reasonable confidence
that nothing will explode if we do that.

Put another way, suppose their was a cross-protocol attack using
WebSockets (with this TLS handshake).  By reduction, I can show that
it's overwhelmingly likely that that cross-protocol attack exists
already because browsers support HTTPS.

I'm aware that you don't usually discuss security issues with browser
vendors, so I'm more than willing to elaborate on these security
considerations.  I know they're not the usual sorts of things that
network security folks think about.

> This is inevitable even without this extension, and it is in fact already

Again, that's a question of whether using end-to-end encryption is a
good idea, not about whether it's a good idea for the folks
participating in the communication to agree about which protocol
they're speaking.

At a more general level, many security problems arise because one
party misunderstands the messages sent by another party.  The goal of
NPN is to make it easier for parties who complete a TLS handshake to
agree on the semantics of the bytes they send over the encrypted
tunnel.

> if SMTP and IMAP were client-speaks-first protocols then it would be

Indeed.  NPN is a less hacky way of doing those things because you
don't need to "sniff" the protocol.  You get a descriptor of what
protocol you're going to speak next, which means fewer
misunderstandings and, therefore, fewer vulnerabilities.

> protocols will become the new way to send/receive email.

Indeed.

Kind regards,
Adam

---

From: Martin Rex <[email-masked]>
Date: Tue, 17 Aug 2010 03:33:11 +0200 (MEST)

> certificate selection process.

Personally, I very much dislike the idea to send the new message type
_before_ rather than after the finished message.  In particular in
combination with the unusal behaviour specified for session resume.

> you are trying to hide by delaying the next protocol until after CCS.

So far SNI is blind about TCP ports, it is only about hostnames.

I do remember serious concerns from the network operations people
when IPsec put the TCP port into the encapsulated payload because
they would no longer be able to accumulate meaningful per-protocol
statistics and discriminate against specific protocols between
two hosts.  In particular, they wanted a requirement that the TCP port
must remain visible on the outside and that implementations
would have to ensure that the TCP port on the outside would not get
simply ignored if the TCP port value inside the encapsulated payload
specified some other port.

Somehow it looks like this approach is going up two protocol layers
to escape the attention and influence of the network operations people. :)

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 16 Aug 2010 20:21:00 -0700

> extension to meet that need.

In the 7 years since RFC 3546, there have been only 17 TLS extensions
defined.  I don't know what gave you the idea that they are "cheap."
Each one needs to be carefully studied to determine how they interact
with each other.

So, no, we won't define one haphazardly.

But to answer your question, I'm not saying that a certificate "should"
depend on the protocol, but it "might" and you should accommodate that.

Once you start multiplexing many services all on a single port, it would
actually be surprising to find that they all have the exact same security
requirements and can all use the same certificates and keys.

Mike

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 16 Aug 2010 21:41:50 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Barth
> Sent: Monday, August 16, 2010 5:30 PM

> It's hard for me to address your non-technical concerns.  The use of NPN for
> WebSockets is not in any way a fist shaking reaction to anything.  It's a
> technical solution to the following technical
> problem:
> 
> 1) The client needs to be convinced that the server wishes to speak the
> WebSocket protocol.
> 
> 2) The server needs to be convinced that the client wishes to speak the
> WebSocket protocol.
> 
> If either party cannot be convinced of that fact, then we leave ourselves
> open to cross-protocol attacks, which is unacceptable in the deployment
> scenarios for WebSockets.

Is there an alternate way to describe this situation?  Maybe that there is a problem with WebSockets?  Are WebSockets always going to use TLS?  If not, don't we have exactly this same security exposure in that case without any cure?   I admit to not being current on my WebSockets reading but the original specs didn't require TLS, and simply did an HTTP-upgrade to WebSockets if the server supported it.  

- Andy

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Aug 2010 21:52:51 -0700

Without taking a position on whether extensions are cheap or not,
I would observe that certificates can contain [extended] key usage
extensions, precisely to avoid e.g., a Web certificate being
used for a SIP server. So, I don't think Michael's concern here is
totally unfounded.

-Ekr

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 16 Aug 2010 22:28:44 -0700

In addition, we mustn't forget about those cipher suites that don't
use certificates.  There are TLS-PSK (pre-shared keys RFC 4279 and
RFC 5487) and TLS-SRP (secure remote password RFC 5054).

It is likely that each service would have its own database of user
names and passwords (I hope!), so you would have to tell the server
which service you want to use before it can negotiate with you.

Mike

Eric Rescorla wrote:
> On Mon, Aug 16, 2010 at 8:21 PM, Michael D'Errico <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Adam Barth wrote:
> 
>

---

From: Geoffrey Keating <[email-masked]>
Date: 17 Aug 2010 02:58:45 -0700

This discussion would be much simpler if WebSockets had a port
assigned to it that was not 443.  We could then focus on the questions
of how to verify that a MITM is not switching ports, and how (and
whether) to protect servers on ports that are reserved for another
purpose, rather than the questions involved in multiplexing existing
and new protocols on the same port.

---

From: Martin Rex <[email-masked]>
Date: Tue, 17 Aug 2010 16:01:01 +0200 (MEST)

> and new protocols on the same port.

Motivations for choice of port 443 appear to be:

 - the ability to sneak by existing firewalls that block everything
   besides 80/443 and deep-inspect 80.

 - the ability to use an existing onion-router setup (Tor) for more
   than just HTTPS traffic.

and I think they're both quite attractive.

I don't know where you see an MITM here.  Unless the client
goofs the server authentication there is no possibility for an MITM.
(at least after plugging the TLS renegotiation flaw, where a
server could decide to force a client into renegotiation and patch
the client's renegotiation handshake through to a completely
different server.)

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 17 Aug 2010 16:36:57 +0200

> Our main reason is latency: we cannot afford a round trip.

If latency is the issue then what if the extra information is sent
together with but prepended to the client hello? Generally talking I
think that TLS is the security provider layer and should remain like
that. Extensions to it should be relevant to TLS and not to some
application protocol on top of it.  For the same reason you don't
extend the IP protocol for what you want to achieve here, you
shouldn't want to extend TLS as well. Layering might not save you a
round-trip but will keep the TLS protocol simple to understand and
extend. There are of course exceptions that the impact of crossing
layers is too good to ignore... but is this such a case?

regards,
Nikos

---

From: Marsh Ray <[email-masked]>
Date: Tue, 17 Aug 2010 11:30:46 -0500

On 08/17/2010 09:36 AM, Nikos Mavrogiannopoulos wrote:
>  Layering might not save you a

It also sounds like one could get 90% there just by doing session 
resumption. The examples given for WebSockets don't seem particularly 
latency-sensitive, at least not on the initial connection (e.g., like a 
chat client). For stuff running in a browser, isn't it reasonable to 
expect that the initial page load has already set up a resumable TLS 
session?

I'm all for experimenting with new and improved protocols, but do it on 
another port, and call it something else if it's not intended to be 
reasonably conformant and interoperable. (Why does WebSockets send 
garbage after a GET request?)

- Marsh

---

From: Adam Barth <[email-masked]>
Date: Tue, 17 Aug 2010 09:49:52 -0700

> combination with the unusal behaviour specified for session resume.

Please read the thread before replying.  Adam Langley has said that he
plans to change the session resume behavior in the next draft.  As for
whether the information is before or after the finish message, I'm not
sure it makes too much of a difference w.r.t. security.  I think the
considerations are mostly performance (i.e., not adding a round-trip).

> to escape the attention and influence of the network operations people. :)

The ability to multiplex WebSockets and HTTPS on the same port is a
requirement in the HyBi working group.  If you don't think that's a
good idea, you should raise those concerns in the HyBi working group.
As things stand, that issue is independent of this TLS extension.

> So, no, we won't define one haphazardly.

I think you misunderstand my message.  I wasn't suggesting that we
define TLS extensions haphazardly.  Rather, I was saying we're be
better off designing a set or relatively independent extensions that
each solve a particular problem well rather than an "all-sing,
all-dance" extension that attempts to address the kitchen sink.

> requirements and can all use the same certificates and keys.

The key problem we're trying to solve with this extension is for the
client and server to agree on the semantics of the bytes traveling
over the encrypted tunnel.  In particular, they each want the other to
confirm that those bytes are to be interpreted according to a
particular protocol.  This is an important security property (e.g.,
for WebSockets) to avoid cross-protocol vulnerabilities.

One can certainly imagine designing a TLS extension to solve the
problem of a server not knowing which certificate it should use (in
fact, SNI is one step in that direction).  However, that problem not
the problem we're trying to solve with this extension.  If we later
find that we're having that problem, a more aesthetic solution would
be to design a TLS extension to solve that problem, which would have
value both in conjunction with NPN and independently.

> used for a SIP server. So, I don't think Michael's concern here is

Indeed.  However, it's a separable concern from the problem of the
client and server agreeing on the semantics of bytes exchanged over
the encrypted tunnel.  If we wish to solve that problem, we should do
so in a separate extension.

> which service you want to use before it can negotiate with you.

See above.

> and I think they're both quite attractive.

Assigning a port to WebSockets does not solve the security problem we
need to solve, as discussed in my previous email.

> the client's renegotiation handshake through to a completely

Cross-protocol vulnerabilities are not related to man-in-the-middle
vulnerabilities.  I know they're not a class of vulnerabilities that
this group routinely thinks about, so I'll elaborate a bit.

Here's an example of an HTTP -> SMTP cross-protocol vulnerability.
Eve is going to abuse Alice's browser to send spam via Bob's server.

1) Suppose Alice visit's Eve's web site with a web browser.
2) Suppose Bob operates an SMTP server on bob.com on port 25.
3) Eve's web site returns to Alice's browser an HTML document
containing a <form> element that points to http://bob.com:25/.
4) Script from Eve's web site instructs Alice's browser to submit the form.
5) Alice's browser sends an HTTP POST request to bob.com on port 25.
6) Bob misinterprets the HTTP POST request as an SMTP session and
finds instructions in the payload of the request to send spam to
Charlie.

Notice that Alice and Bob believe they are speaking different
protocols over the same socket.  Alice believes they are speaking HTTP
whereas Bob believes they are speaking SMTP.  Notice that assigning a
specific port to SMTP (in this case port 25) did not prevent the
attack.

Q) Why doesn't Eve connect directly to bob.com on port 25?  What's the
point of using Alice's browser?
A) SMTP servers commonly use IP-based reputation as part of their spam
filtering algorithms.  By sending the request via Alice's browser, Eve
uses Alice's IP reputation, which is likely to be better than her own.

Q) Isn't this some strange interaction between HTTP and SMTP?  I don't
think any other protocols will have this issue.
A) Over the decade that browsers have been widely deployed, we've seen
a rather large variety of these sorts of cross-protocol attacks.  (I
can give you some more pointers if you want to see them.)  When adding
a new protocol to the browser (e.g., WebSockets), we want to be sure
we're not adding more attack surface for cross-protocol attacks.
Avoiding cross-protocol attacks is a requirement in the HyBi working
group.

Q) Why aren't attackers using this trick all the time to spend tons of spam?
A) The browser defends against these attacks by blacklisting ports.
If you try to submit a form to port 25, you'll get an error telling
you that port is forbidden.  This is a pretty crappy solution, and
certainly not a road we want to go down for new protocols.  For
example, every few years, we find another one of these vulnerabilities
and have to blacklist another port.  :(

On Tue, Aug 17, 2010 at 7:36 AM, Nikos Mavrogiannopoulos
<[email-masked]> wrote:
> together with but prepended to the client hello?

I'm not sure how that would improve latency.  We still need to
complete the TLS handshake before sending data over the encrypted
tunnel.  As currently designed, the extension doesn't add any
additional latency to the handshake.

> Generally talking I
> application protocol on top of it.

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.

> For the same reason you don't
> shouldn't want to extend TLS 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.
Believe me, I would much rather use TCP ports if they worked.

> layers is too good to ignore... but is this such a case?

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.

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.

On Tue, Aug 17, 2010 at 9:30 AM, Marsh Ray <[email-masked]> wrote:
> latency-sensitive, at least not on the initial connection (e.g., like a chat
> client).

Latency is an important considerations for WebSockets.  There's been a
lot of discussion about how to optimize latency in the HyBi working
group.

> For stuff running in a browser, isn't it reasonable to expect that
> the initial page load has already set up a resumable TLS session?

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.

> reasonably conformant and interoperable.

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.

> (Why does WebSockets send garbage after a GET request?)

That's part of the hacky non-TLS defense against cross-protocol
attacks.  The version that uses a TLS-based handshake doesn't have any
of that garbage (to use your term).

Adam

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 17 Aug 2010 12:12:53 -0500

Eric Rescorla wrote:
> The TLS standard (RFC 5246) defines the rules for the assignment of
> code points in these ranges. Extension types may be defined by
> "IETF Consensus" (this requires an IETF LC). Handshake types must be
> defined by "Standards Action" (this means a standards track RFC). 
> This means that as a practical matter NGN as currently constituted will
> need to go through the TLS WG in order to reserve the code point
> through the IETF process. (To state the obvious, vendors can obviously
> grab a code point and say "that's NPN", but I'm assuming the intent is
> to actually follow the IETF standards process here.)

RFC 4680 is an example of an eisting standards-track extension that was
explicitly designed to pass application-level data in the handshake. So, NPN
would not be breaking any new ground.

NPN can be reformulated using RFC 4680 if it doesn't make it onto the
standards track. If it is desirable (as I believe it is) to move the
SupplementalData messages to after the ChangeCipherSpec or Finished messages
for NPN then another TLS extension can be used to negotiate that, and that
extension doesn't need to be on the standards track either.  I am hoping to
submit a draft soon which allows the client to ask for many (most?)
handshake messages to be sent after the Finished messages anyway.

Regards,
Brian

---

From: Marsh Ray <[email-masked]>
Date: Tue, 17 Aug 2010 13:41:46 -0500

> extensions that are appropriate for your use of the protocol.

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

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

> answer, it must be speaking WebSockets.

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

> using a TLS extension to solve this security problem is too good a

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<[email-masked]>  wrote:
>> resumption.

> Facebook web site.  In those cases, we won't have a TLS session to

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.

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

> 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

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

---

From: Adam Langley <[email-masked]>
Date: Tue, 17 Aug 2010 15:04:44 -0400

On Tue, Aug 17, 2010 at 2:41 PM, Marsh Ray <[email-masked]> wrote:
> 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.

I think I might be misunderstanding you. How does session resumption
help here? (If you were thinking about removing a round trip with
session resumption, we've already claimed that with False Start.
Chrome, Android and Firefox (4) are already using False Start so TLS
handshakes are 1 RTT with or without session resumption in our
calculations.)

AGL

---

From: Marsh Ray <[email-masked]>
Date: Tue, 17 Aug 2010 14:44:45 -0500

On 08/17/2010 02:04 PM, Adam Langley wrote:
>
> I think I might be misunderstanding you.

No, I'm sure it is I who am not fully understanding. :-)

> How does session resumption
> help here?

It was just an example of an existing facility with similar goals that 
was often underutilized.

> (If you were thinking about removing a round trip with

Doh!

- Marsh

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 17 Aug 2010 16:00:44 -0500

> Don't allow unauthenticated connections to do anything significant (like
send
> mail) on any port (source IP does not count as authentication).

Following these guidelines would subject the client and server to very
simple and effective DoS attacks, which are already so common that we accept
them as part of the status quo. Relying on these guidelines would subject
the client and server to cross-protocol attacks unless everybody else in the
world follows them.

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

Google, Amazon.com, and others claim significant decreases in revenue that
correlate with increases in latency of 100ms or even less. 

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

Firewall and HTTP proxy administrators are the attackers in the scenarios
that are being defended against. Not every Firewall or proxy is benevolent,
and even many that aren't intentionally malicious are harmful due to poor
implementation or configuration.

> I know WebSockets isn't on trial here, but it seems like one of the main

I think it would be better for this discussion to focus on the actual
security improvements that this extension enables for all protocols.
Otherwise, too much discussion will be about alternatives that work for
WebSockets but don't solve the same problems for other protocols. Here are
the attacks that this extension helps mitigate:

1. Denial of service caused by a MitM that selectively allows traffic based
on the port number; i.e. the firewall attack. This extension allows the
client and server to work around the firewall attack if the attacker has
left any opening, which they almost always do.

2. Traffic analysis that allows a MitM to determine the user's actions even
when the communication is taking place over TLS, using the port number
and/or plaintext information sent in the TLS handshake (SNI extension,
certificates, etc.). For example, currently it isn't possible to build a
system that uses SMTP and IMAP but which hides the user's action (sending or
receiving) from a MitM; this extension (or a similar one) would enable
implementations to make such traffic analysis significantly more difficult
and hopefully prohibitively expensive, especially if used in conjunction
with  a careful padding scheme.

3. Cross-protocol attacks as described by Adam. This extension allows the
client and server to explicitly specify what protocol they expect to be used
on the connection. This is a useful feature even for applications that don't
want to support overloading ports with multiple protocols. It is difficult
to extend application layer protocols with these cross-protocol attack
protections, because those extensions themselves may be exploitable with
cross-protocol attacks.

It is hard to believe that a significant number of attacks can be prevented
simply by using port 443 for everything. But, it would really work a lot of
the time; it is difficult for the attacker to counteract this defense,
because often the attacker has a business or political need to avoid
disrupting HTTPS on port 443; otherwise they would have disabled that
already. The amazing ability of Skype to punch through firewalls is partly
due to such port 443 tunneling.

One thing I will say about this extension in conjunction with WebSockets: I
think that it is unrealistic to expect many service providers to enable or
require TLS simply for the privacy benefits of their users. Many service
providers do not care about their users' privacy enough to spend any extra
money to protect it. If this extension becomes the standard way to enable
interoperable WebSockets support, then even service providers that are
apathetic about MitM protection might having a compelling reason to use TLS.
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.

Cheers,
Brian

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 17 Aug 2010 16:30:50 -0700

Last night at about midnight I awoke with a revelation
that this whole WebSockets protocol could be a hoax.
But assuming that it is real, here are some things that
concern me:

   - You have managed to take a binary-capable
     transport (HTTP) and turn it into a text-only
     non-binary capable transport.

   - The "framing" used to delineate messages sent
     over the protocol is sentinel-based similar to
     the C programming language string handling that
     uses NULL, but WebSockets uses 0xFF since it is
     invalid in UTF-8.  That means both the sender
     and receiver need to scan every byte of every
     message for the sentinel, which takes time and
     therefore increases latency.

   - Any text data that is in a different character
     set (e.g. ISO-8859-1) has to be converted to
     UTF-8 in order to be sent which adds latency to
     the protocol.

   - Am I missing something, or why didn't you use
     the "chunked" transfer coding of HTTP?  It gives
     you binary transfer (and therefore you can send
     UTF-8 over it too) and eliminates the need to
     inspect every byte sent and received.  If just
     the length was not enough for your framing needs,
     I'll point out that you can add chunk extensions
     and even send headers after the last chunk, all
     without changing HTTP.

   - The sentinel-based framing is a problem because
     it can be trivially broken by sending FF 00 and
     then any payload you want.  (This is why the
     sender also needs to scan all outbound traffic).

Collectively you are trying to "fix" TLS to solve your
latency problems, but as noted above you have some
things you can do to improve your own protocol first.

As they say, "get your own house in order."  Apologies
if that sounds harsh.

Mike

P.S. I hope that this is not the network protocol
version of getting rickrolled.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 17 Aug 2010 19:14:42 -0500

> the client and server to cross-protocol attacks unless everybody else in the

I don't get it, it's basic stuff. What part of those recommendations 
"subject the client and server to simple and effective DoS attacks" in a 
way that they weren't already?

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

Oh and I forgot: disable NTLM (my latest crusade).
http://extendedsubset.com/?p=36

> correlate with increases in latency of 100ms or even less.

Interesting, I had heard of that. Link?

I like a snappy web site as much as anybody, but this WebSocket thing 
seems somewhat ancillary. Possibly some of these app-heavy pages would 
improve the perceived responsiveness if they would just load the HTML 
and size the rectangles fully before starting with a zillion background 
requests.

> implementation or configuration.

Never pick a fight with the guy who's holding your power cord.
He wins every time.

> left any opening, which they almost always do.

By definition, it cannot be an attack if it's by the equipment's 
rightful owner. You seem to be of the opinion that you or some other 
entity have some kind of right of transit over private networks. I 
believe one should acting like a respectful invited guest on another's 
network. Displaying that arrogant attitude is a large part of why admins 
are distrustful of new network software and have resorted to blocking 
everything by default.

If you are actually in some kind a repressive political environment you 
might be better served with a special purpose VPN solution designed for 
strong anonymity.

> with  a careful padding scheme.

This is expected to make it hard for TA to distingush between HTTP, 
SMTP, and IMAP? Really?

> protections, because those extensions themselves may be exploitable with

I can see how this could be an improvement.

Consider the status quo, I open an url into a browser: 
https://www.example.com/

https:           = specifies HTTP over TLS
www.             = a convention associated with HTTP
example.com      = the only useful part
DNS lookup 'example.com'
DNS lookup 'www' = resolve servers for HTTP
TCP port 443     = assigned port for HTTP over TLS
Baked into server's cert: "Ext key usage = TLS Web Server Auth" = HTTP
Client request 1: "GET / HTTP/1.1"         HTTP
Client request 2: "Host: www.example.com"  www -> HTTP again
Server response: "HTTP/1.1 200 OK"         HTTP

In this simple example we already have the protocol "HTTP" stated 
explicitly or associated by convention ten times!

One might think this would be good enough to indicate what the intended 
protocol is, but as you say there are apparently people with 
unauthenticated SMTP and IMAP servers listening on port 443.

My question is this: What's going to be different this time?

If we really need another protocol identifier because the ones we have 
don't hold up under attack, let's do it right this time! It needs to be 
treated just as security-critical as checking the name on a server 
certificate.

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.

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?

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?

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?

How is client cert auth to be performed? Is it a problem that it's not 
configurable per-protocol?

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

Insecure (without RFC 5746) renegotiation can now easily be a 
cross-protocol attack. Should this spec forbid it?

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?

Should the client's SNI be allowed to or prohibited from influencing the 
server's list of supported protocols?

Would it be advantageous for the client-selected protocol to be allowed 
to influence the cert presented by the server? It's not unusual to need 
different certs for different protocols after all. Can this be 
accomplished through renegotiation? Wouldn't that leak information about 
what protocol was chosen?

Will this have implications for protocols that need to poke holes for 
incoming connections  E.g., STUN, UPnP?

> due to such port 443 tunneling.

I used to work for a VPN company. We prided ourself on our client 
software being able to find a way back to the datacenter with minimal 
user intervention in nearly all circumstances. But we were also not 
going to go around boasting "Ha ha we can exfiltrate through anything 
you leave open I dare you to block [method X] Mr. Admin we pwn ur netz".

There's no way an IETF protocol can "lie low" in this respect. If the 
proposed scheme gains widespread adoption, firewalls will of necessity 
evolve to manage it (regardless of whether that can be done correctly).

http://www.google.com/search?q="Data+Loss+Prevention"+ssl

It's one thing for a P2P app to disregard the admin's preferences, they 
are budgeting ongoing development time to continually evolve their 
connection smuggling techniques in a cat-and-mouse arms race. But an 
IETF protocol is a different matter. It's published, it gets used, 
vendors sell boxes to accelerate and manage it, admins deploy the boxes 
as well as other tools.

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.

> require TLS simply for the privacy benefits of their users.

Agreed.

> Many service

But if it requires a software (if not hardware) upgrade to support the 
extension, wouldn't that just encourage deployments to use plain HTTP?

> integrate this mechanism into TLS.

That would be nice, but it doesn't seem likely. For example, I use two 
"social networking" sites, Twitter and LinkedIn. They both appear to 
support https urls, but fail in several ways. The sites regularly load 
resources (even script) from plain http urls. Clicking on links 
sometimes drops back to http. When they send emails or alerts from other 
apps, the links are all http. Twitter actually looks like it's gotten a 
bit better, but LinkedIn seems to just redirect me away from https 
completely. The point being that making a secure site requires a 
commitment to a significant development project.

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.

- Marsh

---

From: Adam Barth <[email-masked]>
Date: Tue, 17 Aug 2010 21:21:41 -0700

> that this whole WebSockets protocol could be a hoax.

I assume you that WebSockets is not a hoax.

Your opinion appears to be based on an older version of the protocol.
Many of your complaints below have been addressed in more recent
versions of the protocol.  If you're interested in this work, I
encourage you to participate in the HyBi working group.

On Tue, Aug 17, 2010 at 5:14 PM, Marsh Ray <[email-masked]> wrote:
>> the client and server to cross-protocol attacks unless everybody else in
>> the world follows them.
>
> "subject the client and server to simple and effective DoS attacks" in a way
> that they weren't already?

I'm sorry, but I don't understand your question.  Cross-protocol
vulnerabilities need not be related to DoS.  In particular, the
example I gave earlier in the thread was about spam.

> options in the event of an actual DoS (possibly inadvertent).

Indeed.  We're not talking about DoS protection.

> http://extendedsubset.com/?p=36

I don't understand how this relates to the topic at hand.

> Interesting, I had heard of that. Link?

This is a well-established fact.

> I like a snappy web site as much as anybody, but this WebSocket thing seems
> somewhat ancillary. Possibly some of these app-heavy pages would improve the
> perceived responsiveness if they would just load the HTML and size the
> rectangles fully before starting with a zillion background requests.

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.

> By definition, it cannot be an attack if it's by the equipment's rightful
> owner. You seem to be of the opinion that you or some other entity have some
> kind of right of transit over private networks. I believe one should acting
> like a respectful invited guest on another's network. Displaying that
> arrogant attitude is a large part of why admins are distrustful of new
> network software and have resorted to blocking everything by default.
>

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.  The purpose of this TLS extension is to improve the
security of the protocol, not to enable multiplexing.

> This is expected to make it hard for TA to distingush between HTTP, SMTP,
> and IMAP? Really?

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.

> I can see how this could be an improvement.

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

[Snip example]

> In this simple example we already have the protocol "HTTP" stated explicitly
> or associated by convention ten times!
>
> protocol is, but as you say there are apparently people with unauthenticated
> SMTP and IMAP servers listening on port 443.

Folks can run whatever services they like on whatever port they like.
It's our job not to introduce vulnerabilities into their deployments.

> My question is this: What's going to be different this time?

The difference is that it's a prior reasonable for a web page to
generate an HTTP POST request to port 25 on smtp.example.com.  It's
only after we learn of HTTP -> SMTP cross protocol attacks that we
need to look for a heuristic to block the attack.  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.  The extension adds the
semantics that are present only heuristically currently, letting us
gain a strong security property.

> If we really need another protocol identifier because the ones we have don't
> hold up under attack, let's do it right this time! It needs to be treated
> just as security-critical as checking the name on a server certificate.

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

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

> 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.  Are you reading the same document I am?
Where's the dependence on TCP?

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

> Are any security properties associated with some names and not others? Is
> there an equivalent to privileged "low numbered ports"? Should OS

No.  The semantics of the protocol are defined by the protocols themselves.

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

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

I'm not familiar with this design.  You're seem unduly concerned with
multiplexing.  That's not the essential feature here.  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.

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

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

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

> Would it be advantageous for the client-selected protocol to be allowed to
> influence the cert presented by the server? It's not unusual to need
> different certs for different protocols after all. Can this be accomplished
> through renegotiation? Wouldn't that leak information about what protocol
> was chosen?

This issue has been discussed previously on this thread.  Please read
my prior responses for the answer to your question.

> incoming connections  E.g., STUN, UPnP?

No.

> I used to work for a VPN company. We prided ourself on our client software
> being able to find a way back to the datacenter with minimal user
> intervention in nearly all circumstances. But we were also not going to go
> around boasting "Ha ha we can exfiltrate through anything you leave open I
> dare you to block [method X] Mr. Admin we pwn ur netz".

This paragraph seems like a non-sequitur.

> It's one thing for a P2P app to disregard the admin's preferences, they are
> budgeting ongoing development time to continually evolve their connection
> smuggling techniques in a cat-and-mouse arms race. But an IETF protocol is a
> different matter. It's published, it gets used, vendors sell boxes to
> accelerate and manage it, admins deploy the boxes as well as other tools.
>
> 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

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.
 Currently, that working group takes the opposite viewpoint as a
requirement of the protocol, regardless of whether the protocol
involves NPN.

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

>> 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
> "social networking" sites, Twitter and LinkedIn. They both appear to support
> https urls, but fail in several ways. The sites regularly load resources
> (even script) from plain http urls. Clicking on links sometimes drops back
> to http. When they send emails or alerts from other apps, the links are all
> http. Twitter actually looks like it's gotten a bit better, but LinkedIn
> seems to just redirect me away from https completely. The point being that
> making a secure site requires a commitment to a significant development
> project.
>

Be that as it may, it's irrelevant to topic currently under discussion.

Adam

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 17 Aug 2010 21:27:48 -0700

Adam Barth wrote:
> versions of the protocol.

Well I skimmed through the 76th (!!!) revision of the internet draft
which was the most recent available....

Mike

---

From: Adam Barth <[email-masked]>
Date: Tue, 17 Aug 2010 21:46:20 -0700

> which was the most recent available....

As, that's before the draft was adopted as a WG item.  The working
group is in the midst of changing editors.  The most recent version of
the protocol can be found here:

http://www.whatwg.org/specs/web-socket-protocol/

I expect we'll see a -01 version of
draft-ietf-hybi-thewebsocketprotocol shortly once the new editor gets
up to speed.

Adam

---

From: Marsh Ray <[email-masked]>
Date: Wed, 18 Aug 2010 01:45:29 -0500

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

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

> Indeed.  We're not talking about DoS protection.

I wasn't the one who brought it up.

> I don't understand how this relates to the topic at hand.

Cross protocol attack.

> This is a well-established fact.

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

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

> 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

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.

> description of the security properties we seek to obtain with this

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

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

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

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.

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

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.

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

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

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

>> Is it a problem that it's not configurable per-protocol?

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.

> 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

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.

> address occur in a different threat model than the one we're concerned

I see.

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?

> opts to complete the handshake.

OK.

> This paragraph seems like a non-sequitur.

You cut out the part I was replying to.

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

> requirement of the protocol, regardless of whether the protocol

I don't understand.

> did, there would be no need to invest in WebSockets.

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

> 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

---

From: Adam Barth <[email-masked]>
Date: Wed, 18 Aug 2010 01:42:35 -0700

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

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

> draft-agl-tls-nextprotoneg-00 is acutally proposing.

Feel free to read the draft.

> So the purpose of NPN is to improve security of "the protocol". Which

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.

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

Precisely.

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

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

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

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

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

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

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

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

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

> WebSockets beyond skimming the Wikipedia artice.

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

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

> expectations from OS-land about how such a resource should be shared and

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

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

Indeed.

[Snip a bunch of redundant text about multiplexing.]

>> encrypted tunnel.  WebSockets would want NPN even if it were always

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

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

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

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

> general utility to TLS (or is part of some unspecified grand plan) is

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.

> 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

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 18 Aug 2010 12:37:07 +0300

> Thanks for your feedback.  This looks to be an area in which we can

This is a serious concern so far, since if the selected_protocol is not very well defined, two different users of the NPN extension might be conflicting. I don't know if using the port assignments is a good idea, since there are many undocumented and conflicting port uses as well. On the other hand a string identifier just feels a bit dirty...

> instead of the hacky nonce/MD5 handshake that "sorta" looks like plain

If that handshake is garbage, are there similar plans to "fix" the plain HTTP version of WebSockets, or is the plan that NPN would be used with TLS and the old handshake is used with HTTP? This sounds like it makes the life of WebSockets implementors a much harder, since they have to consider two completely different schemes, wouldn't it?

Since the plan of NPN is to improve the security of WebSockets, what kind of attacks it protects against, compared to simply having the HTTP style handshake negotiation inside a secure TLS connection? I understand that the protocol is much "cleaner" in a way with NPN, but in case it is to be used the earlier concerns about selecting a correct certificate based on the protocol type are valid as well. I think having the NextProtocol handshake message before the ChangeCipherSpec and using renegotiation in case the contents need to be protected could be considered.

Sorry if some questions are already answered, this is a long thread and I haven't read all the messages that carefully. I'm just trying to sum up here what I've seen so far.

Juho

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 18 Aug 2010 10:36:21 -0500

Marsh Ray wrote:
> > simple and effective DoS attacks, which are already so common that we
> > accept them as part of the status quo. Relying on these guidelines
> > would subject the client and server to cross-protocol attacks unless
> > everybody else in the world follows them.
> 
"subject the
> client and server to simple and effective DoS attacks" in a way that they
weren't
> already?

TLS is used to protect the end entities from MitM's. If a MitM is filtering
the endpoints' traffic based on the port number or any other criteria, then
that is a denial of service. Whether the end entities are the good guys or
the MitM is the good guy, or whether the end entities are abusing the MitM's
network isn't relevant. 

> Never pick a fight with the guy who's holding your power cord.

It isn't practical to disable port 443 for most ISPs for a variety of
business and political reasons.

> By definition, it cannot be an attack if it's by the equipment's rightful
owner. 

The rights of the participants are outside the scope of the discussion. TLS
protects the end entities from everybody else, even if the end entities are
actively, criminally, attacking the network they are using or worse, and
even if the network administrator is the cutest puppy in the world.

> > For example, currently it isn't
> > possible to build a system that uses SMTP and IMAP but which hides the
> > user's action (sending or
> > implementations to make such traffic analysis significantly more
> > difficult and hopefully prohibitively expensive, especially if used in
> > conjunction with  a careful padding scheme.
> 
and
> IMAP? Really?

Yes, I think it is easy to make it prohibitively expensive for a MitM to use
TA to recognize what application protocol is in use with actionable
certainty for many use cases.

> In this simple example we already have the protocol "HTTP" stated
explicitly or
> associated by convention ten times!
> 
unauthenticated
> If we really need another protocol identifier because the ones we have
don't
> hold up under attack, let's do it right this time! It needs to be treated
just as
> security-critical as checking the name on a server certificate.

Yes, This is definitely something that needs work in the NPN draft.

> How is client cert auth to be performed? Is it a problem that it's not
configurable
> per-protocol?

I would say the server shouldn't ask for a client certificate until after
the first handshake, for a variety of reasons, some of which aren't specific
to this extension.

> Insecure (without RFC 5746) renegotiation can now easily be a
cross-protocol
> attack. Should this spec forbid it?

I think any implementation can and should require that if the other end
implements this extension, then the other end also supports secure
renegotiation--simply because it is stupid to add support for this extension
but ignore secure renegotiation.

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

The TLS WG should work on a general way of securing the information
transmitted in the handshake, by doing key exchange first and transmitting
everything else afterwards. The results presumably would have the effect you
are looking for.
 
> influence the cert presented by the server? It's not unusual to need
different
> certs for different protocols after all. Can this be accomplished through
> renegotiation? Wouldn't that leak information about what protocol was
> chosen?

If you have different certs for different protocols, then that leaks
information about the protocol, unless you transmit the protocol-specific
certs during a renegotiation and everything is worked out perfectly to
prevent traffic analysis. More realistically, the service provider probably
needs to make a choice between using this extension and per-protocol
certificates, to avoid the latency that a double handshake would require,
and to avoid traffic analysis if nondisclosure of the protocol in use is a
consideration.

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

If nothing else, this TLS with this extension would reduce protocol
complexity for all other protocols that it is used with because it would
provide a standard mechanism for preventing cross-protocol attacks.

> > Many service
> > providers do not care about their users' privacy enough to spend any
> > extra money to protect it. If this extension becomes the standard way
> > to enable interoperable WebSockets support, then even service
> > providers that are apathetic about MitM protection might having a
compelling
> reason to use TLS.
extension,
> wouldn't that just encourage deployments to use plain HTTP?

I think soon we'll see HTTP/Websockets/SPDY over TLS outperform plain
unprotected HTTP for less cost for a variety of reasons in a lot of common
applications, and the benefits will outweigh the costs, even from a purely
financial standpoint.

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

I don't think it is valid to argue that a change to TLS makes it useful to
more people, but those people might not understand the security issues well
enough to use it safely, so the changes must not be made. It's better to
find ways of improving the safety and usability of TLS when it is being
managed by users with little understanding of proper security procedures or
who have little motivation to follow proper security procedures. That's a
topic for another thread.

Regards,
Brian

---

From: Marsh Ray <[email-masked]>
Date: Wed, 18 Aug 2010 10:52:30 -0500

On 08/18/2010 03:42 AM, Adam Barth wrote:
> different people with different interests.

My memory is unpredictable sometimes, but how could I forget Adam Barth?

You sat directly to my right on Sept 29, 2009 at that meeting in
Mountain View. You wore, I believe, a white tshirt with colored trim.
Possibly denim shorts and flip-flops? Unshaven. Pretty much the opposite 
of your current Twitter icon! You had a small white Mac. I wondered if 
you really did all your document reading and writing on that thing. I 
wasn't watching what you were typing, but I did notice you were IM-ing a 
bunch.

Adam Langley, however, I don't recall ever having met in person.

---------

Forgive me for chopping up the thread, I think we're getting to the 
substance of the issue:

About the non-normative text it appears that "the motivation in the 
draft is outdated". So this review will have to disregard it.

 > 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 there's nothing in draft-agl-tls-nextprotoneg-00 about that. If it 
really is building on another WG's work I'd expect a stable normative 
reference and a mapping relating the definitions in that standard to the 
new protocol elements.

Try this: Find someone who's technical, but not involved WebSockets, to 
read the I-D. Then ask them to explain it back to you.

For an I-D describing an extension to TLS, I'd expect it would include 
enough details that a person "skilled in the art" could implement it 
correctly and make testable predictions about the behavior of the 
resulting system. Probably it should even do something demonstrably 
useful to someone.

Yet, on the face of it, this I-D is completely meaningless. It proposes 
a new TLS extension with absolutely no defined semantics. It amounts to 
an empty Client Hello extension, a Server Hello extension containing 
unbounded arbitrary data, and a new handshake message containing up to 
512 bytes such that "The format of this data is not specified in this 
draft".

Allowing big quantities of arbitrary data immediately before the 
Finished message concerns me from a cryptographic perspective. It also 
seems like simple implementation errors could permit attacks where an 
endpoint confuses the new message with a Finished message, or vice-versa.

Other proposals have suggested sending opaque data in one direction or 
another and were not accepted, largely on the grounds that permitting 
non-semantic data in the handshake (data that the TLS RFCs were 
prohibited from interpreting) could only lead to interoperability issues 
(or even de facto usurpation of the protocol by entities outside the 
IETF processes). I realize that that is absolutely not the intent here.

In the opinion of this reviewer, draft-agl-tls-nextprotoneg-00 needs 
substantial rework before it should move ahead in the standardization 
process.

Suggested actions:

1. This appears to be a basic authentication problem. The I-D should 
give a rationale for:

1a. TLS already does strong authentication, and there are plenty of 
other well-understood schemes (from simple to complex). Why are these 
not sufficient?

1b. Couldn't this be done in the app data layer? Is the motivation just 
to save a round trip? Surely plenty of other protocols could shave off a 
round trip with custom TLS extensions, why does this case in particular 
justify it?

2. Decide if it's really (A) specific to WebSockets or it's a (B) 
generally useful mechanism. B is an ambitious project in its own right, 
there's no shame in A.

If A: Get the WebSockets spec solid enough to implement from and serve 
as a stable normative reference.

If B: Define the contents of the fields well enough that they can be 
unambiguously implemented, tested, and interoperate. The protocols being 
authenticated should map to some IANA registry.

- Marsh

---

From: Adam Langley <[email-masked]>
Date: Wed, 18 Aug 2010 12:13:25 -0400

On Wed, Aug 18, 2010 at 11:52 AM, Marsh Ray <[email-masked]> wrote:
> About the non-normative text it appears that "the motivation in the draft is
> outdated". So this review will have to disregard it.

Indeed. Since the initial draft other uses of NPN have been found and
are probably more compelling. I'm rewriting the motivation at the
moment.

AGL

---

From: Adam Langley <[email-masked]>
Date: Wed, 18 Aug 2010 14:29:02 -0400

> are probably more compelling. I'm rewriting the motivation at the

The draft has been so updated. The only changes are that the
introduction has been rewritten.

http://www.ietf.org/id/draft-agl-tls-nextprotoneg-01.txt

1. Introduction

As the Internet has evolved, it has become commonplace for hosts to
initiate connections based on untrusted and possibly hostile data.
HTTP [RFC2616] clients are currently the most widespread example of
this as they will fetch URLs based on the contents of untrusted
webpages.

Any time that a connection is initiated based on untrusted data there
is the possibility of a cross-protocol attack.  If the attacker can
control the contents of the connection in any way (for example, the
requested URL in an HTTP connection) they may be able to encode a
valid message in another protocol.  The connecting host believes that
it is speaking one protocol but the server understands it to be
another.  The application of Postel's Law exacerbates the issue as
many servers will permit gross violations of the expected protocol in
order to achieve maximum compatibility with clients.

The WebSockets [websockets] protocol seeks to allow low-latency,
full-duplex communication between browsers and HTTP servers.  However,
it also permits an unprecedented amount of attacker control over the
contents of the connection.  In order to prevent cross- protocol
attacks, a mechanism to assure that both client and server are
speaking the same protocol is required.  To this end, Next Protocol
Negotiation extends the TLS [RFC5246] handshake to permit both parties
to agree on their intended protocol.

AGL

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 18 Aug 2010 12:09:14 -0700

> This is a well-established fact.

This needs clarification.  I interpret the statement as:

    Google et. al. claim significant decreases in revenue
    when their latency is (x + 100ms) versus when latency
    is x.

What is x?

Mike

---

From: Adam Langley <[email-masked]>
Date: Wed, 18 Aug 2010 15:15:29 -0400

>   when their latency is (x + 100ms) versus when latency

I have asked management at Google to release hard numbers on this
before and I'm afraid that we simply can not release revenue/latency
numbers like that, even for previous years.

However, as evidence of how important latency is, witness the amount
of work that we are putting into it. (SPDY, Google DNS, Snap Start,
False Start, NPN, ...)

AGL

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 18 Aug 2010 12:40:41 -0700

> of work that we are putting into it. (SPDY, Google DNS, Snap Start,

Without knowing that number I'm reluctant to help you modify TLS into
an unrecognizable protocol.  If x is 300ms for example, there is reason
to think that maybe some modification to TLS could help.  But if it is
say, 2.6 seconds, then no, there isn't.

My TLS implementation performs a full handshake (RSA 1024-bit key) on
localhost (i.e. not going over the network) in less than 5 milliseconds.
A session resumption takes around 500 MICROseconds.  (ECC cipher suites
should further reduce the full handshake timing.)  TLS just doesn't
have that much overhead!

So please convince Google that it's in their best interest to publish
a number.

Mike

---

From: Adam Langley <[email-masked]>
Date: Wed, 18 Aug 2010 15:48:42 -0400

> should further reduce the full handshake timing.)  TLS just doesn't

The computational overhead of TLS is unimportant for many applications
and is only becoming less important over time.

However, the number of round trips is critical. However fast the hosts
might be, the speed of light always stays the same.

AGL

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 18 Aug 2010 13:26:54 -0700

> and is only becoming less important over time.

Glad you agree.

> might be, the speed of light always stays the same.

So then NPN is all about reducing a round trip?  You say you already
achieve that with false start.  Or do you need something in addition
that can only be achieved by sticking it in a TLS extension?

Sorry if this was answered before, but it is really hard to follow a
single message that is a line-by-line reply to 4 other messages.

<Somewhat off topic>

Every morning when I first get to my computer, I have to log in.  That
takes a few seconds.  My browser is already running because I hardly
ever shut it down.  I proceed to click the EXACT SAME 4 LINKS that I
click every morning.  I then wait several seconds for these pages to
load.

Do you see the problem here?  Everything waits for me to initiate an
action that is predictable.  The moment I touch the mouse, it is 100%
predictable which 4 links I'm going to click on within the next 15
seconds.  Yet nothing happens until after I type my password, after I
unhide the browser window, after I create 4 tabs, and then click on
the links.

This should all happen automatically so that I don't have to wait at
all for any of these four pages to load.  They will likely be fully
loaded and presentable before I even finish typing my password.

THAT is what you should be working on.  Prediction.  If I've clicked
the same link every morning for the past 18 months, what are the odds
that I'm going to click it today?  100%.  And even if for some reason
I don't, I'm not going to be at all upset that my browser fetched the
page for me.

</Somewhat off topic>

Mike

---

From: Nathaniel W Filardo <[email-masked]>
Date: Wed, 18 Aug 2010 16:47:56 -0400

On Wed, Aug 18, 2010 at 02:29:02PM -0400, Adam Langley wrote:
>[snip] 

I realize this is the TLS mailing list, but...

WebSockets are, AFAIK, designed to have a mandatory HTTP-alike header
specifically so that they can be discriminated from HTTP without requiring
any lower level identification being necessary (though apparently the drafts
of the WS specification are less than perfect about maintaining this
guarantee).  In any case, this ought to render any concerns of being unable
to make WS connections while still making HTTPS connections moot; they can
_already_ be intermixed on port 443.  Moreover, cross-protocol attacks do
not require the advanced control present in WS (though surely it helps);
HTTP has proven to be sufficiently useful to carry out cross-protocol
attacks against both SMTP and IRC servers.  It seems odd to me that secure
WS is the forcing issue here.

It also seems very odd to me that this is being viewed as a TLS-only thing.
Cross-protocol attacks are not limited to the world of secured TLS streams
(see above), and TCP ports are not in fact protocol identifiers, despite
some traditions that conflate the two concepts.  If cross-protocol attacks
are a concern (and I'm not saying they're not), then TLS NPN is necessary
but insufficient -- the outer layers and insecure links must also be
protected.

Further, protocols inside TLS are already implicitly weakly protected if the
endpoints require authentication.  There isn't any way that my web browser
can carry out an HTTPS cross-protocol attack against an SMTPS server, unless
the attacker already knows the appropriate SMTP credentials or I have client
certs accepted by the SMTPS server loaded in my browser.  Any attempt the
browser makes at authenticating via HTTP mechanisms is going to be ignored
by the SMTPS server.  If I require STARTTLS for SMTP, I'm in an even better
position than if I were using just SMTPS, as the client cert issue is gone.
(Would that the HTTP world actually believed in Upgrade: for starting TLS!)

Are there, in fact, attempts to mark sender's intended protocol outside of
TLS being concurrently worked on (perhaps by extending the use of IPv6's
Next Header field across the TCP header)?  If not, why should we believe
that standardization and adoption of a TLS-only NPN will help much at all?

Thanks.
--nwf;

---

From: Marsh Ray <[email-masked]>
Date: Wed, 18 Aug 2010 15:50:44 -0500

> that can only be achieved by sticking it in a TLS extension?

If you're using false start, then the inital application data can go out 
in the same packet as a handshake message before Finished, at least in 
one direction, right?

If I understand correctly, the cross protocol DoS prevention is 
accomplished by requiring the client to send something to the server to 
unambiguously signal the use of a specific protocol.

Can't you use some nonces already present in the handshake without 
extending the protocol? A new handshake message is a big deal, I don't 
think it's been done since SSLv2->v3.

For example, couldn't you have the client and server exchange something 
like:

"[protocol: WebSockets " + MD5(TLS session ID  + "WebSockets") + "]\r\n"

as the initial false start application data?

> I don't, I'm not going to be at all upset that my browser fetched the

Sounds like you were reading:

http://online.wsj.com/article/SB10001424052748704901104575423294099527212.html

No thank you :-)

- Marsh

---

From: Adam Barth <[email-masked]>
Date: Wed, 18 Aug 2010 13:59:42 -0700

> This is a serious concern so far, since if the selected_protocol is not very well defined, two different users of the NPN extension might be conflicting. I don't know if using the port assignments…

It seems likely we'd want an IANA registry to avoid conflicts, similar
to the HTTP header registry.

> If that handshake is garbage, are there similar plans to "fix" the plain HTTP version of WebSockets, or is the plan that NPN would be used with TLS and the old handshake is used with HTTP? This sou…

The plan is to remove the HTTP version.

> Since the plan of NPN is to improve the security of WebSockets, what kind of attacks it protects against, compared to simply having the HTTP style handshake negotiation inside a secure TLS connection?

Cross-protocol attacks, as described above.  I know the thread has
gotten pretty long, but hopefully you'll be able to find the answer
now that you have the key words.

> I understand that the protocol is much "cleaner" in a way with NPN, but in case it is to be used the earlier concerns about selecting a correct certificate based on the protocol type are valid as well. I think having the NextProtocol handshake message before the ChangeCipherSpec and using renegotiation in case the contents need to be protected could be considered.

Indeed.  That does seem worth considering.

> Sorry if some questions are already answered, this is a long thread and I haven't read all the messages that carefully. I'm just trying to sum up here what I've seen so far.

Yeah, I imagine this thread is pretty unapproachable at this point.  :-/

> WS is the forcing issue here.

Browser vendors do not want to add more attack surface.  We're stuck
with HTTP, but that doesn't mean we should add more protocols that
make the same security mistakes.

> but insufficient -- the outer layers and insecure links must also be

We're not trying to solve cross-protocol attacks for every protocol in
the work.  We're trying to design a new protocol that is immune to
cross-protocol attacks.

> (Would that the HTTP world actually believed in Upgrade: for starting TLS!)

That's not an accurate understanding of how cross-protocol attacks
work.  Whether or not we're inside a TLS tunnel, the issues are the
same.  One way to understand this is to think about a VPN.  Clearly it
doesn't matter whether the cross-protocol attacks are taking place
inside an IPv6 tunnel, does it?

> that standardization and adoption of a TLS-only NPN will help much at all?

I'd in fact prefer to use IPv6, but WebSockets must work with IPv4.

Kind regards,
Adam

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 18 Aug 2010 14:14:48 -0700

> http://online.wsj.com/article/SB10001424052748704901104575423294099527212.html 

No, no, no, not at all what I was suggesting.

For example, I open a link to my spam folder every morning so I can check
for false positives.  That page takes forever to load, so waiting for it
is tedious.  I'd like that page to start loading the instant my computer
knows I'm sitting in front of it.  Same thing for a few other pages.  By
the time I actually get to my browser, these pages that I look at every
morning could all be there fully rendered, so I don't have to wait even a
millisecond.

[Since this is off topic, I won't further comment on it.]

Mike

---

From: Marsh Ray <[email-masked]>
Date: Wed, 18 Aug 2010 16:38:38 -0500

> the work.  We're trying to design a new protocol that is immune to

But, by definition, such an attack involves arbitrary other protocols.

> On Wed, Aug 18, 2010 at 2:37 AM, Juho Vähä-Herttua<[email-masked]>  wrote:

TLS normally provides decent authentication. Cross-protocol attacks over 
TLS connections are only possible because the authentication only covers 
the DNS name of the server.

It should probably also include the intended protocol. I've seen some 
hints of that with in various x509 fields, but they don't appear to be 
marked 'critical'.

> inside an IPv6 tunnel, does it?

It seems like certificates could be used to authenticate the server's 
hostname and also the intended protocol (in both directions!), were it 
not for the distortions induced by the PKI business.

 >> (Would that the HTTP world actually believed in Upgrade: for 
starting TLS!)

Those mechanisms are typically subject to downgrade attacks.

- Marsh

---

From: Nathaniel W Filardo <[email-masked]>
Date: Thu, 19 Aug 2010 03:30:21 -0400

> inside an IPv6 tunnel, does it?

The particular class of attacks you're worried about all involve an agent,
C, making requests to a server S, on behalf of some untrusted third party,
M.  Further, S thinks that it is speaking P and C thinks that it is speaking
Q, with P != Q.  It happens to be that S's interpretation of P is compatible
with C's production of Q.  Is that not an accurate understanding?

For concrete example, in the case of P=SMTP and Q=HTTP, M requests that C
make a POST request to S; S in turn will typically ignore C's HTTP
verb/object/version line and any headers.  Reason being, HTTP verbs and
options (which all involve a : before whitespace) don't overlap with the
SMTP vocabuarly, and so S ignores them as malformed lines.  Note that TLS
NPN does _nothing_ to help here, since TLS is not involved.  _Every_
cross-protocol attack I am aware of is of this class; if you can provide
citations otherwise, I would love to see them.

Now, we can ignore (P,Q) being (SMTP,HTTPS) or (SMTPS,HTTP) since neither
off-diagonal form is going to be able to bring up the TLS session to
everybody's satisfaction.

(P,Q)=(SMTPS,HTTPS) with neither C nor S expecting to see authentication
essentially behaves as (SMTP,HTTP), I agree; TLS NPN helps here.

(P,Q)=(SMTPS,HTTPS) with S expecting C to authenticate will result in a
cross-protocol attack iff either of the following conditions are met:
  1. C has a client certificate which S will accept and S does not expect
     in-band authentication.
  2. M has been able to specifically craft a P-message involving suitable
     credentials for C's use in this transmission.
Neither of these are terribly realisitic (in my mostly speculative opinion).
Note that if S's knobs are set such that P requires a challenge-response
authentication pass, that M will, whp, be unable to successfully take option
2.  TLS NPN doen't hurt here, but there's not a lot of headroom for it to
help -- the connection is likely going to fail anyway.

That was the only claim I was making.

In all, while I have no intrinsic objection to TLS NPN, it seems to me that
the solution should be independent of the cryptographic provisioning layer,
since it demonstrably has nothing to do with said functionality.

--nwf;

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Aug 2010 16:20:30 +0200 (MEST)

> This is a well-established fact.

When I'm at home (DSL ~2500/600), I can boost the rendering of
pages by 2x using Adblock plus (Firefox).  And NoScripts give me
some more performance back (but requires more "personal training" in
distinguishing friend and foe).  There's is likely no amount
of additional(!) wrapping you could add with WebSockets+NPN that comes
even close to that.

And frankly, I'm actually glad that I can choose my Email MUA seperate
from my Web Browser and don't mind when my Web Browser denies connects
to any port below 1024 besides 80/443.  Our companies firewall is
limited to 80/443 and while there are occasionally other ports
that would find useful being able to use, none of them is below 1024
(from those where connecting with a browser makes sense).

What I fail to understand is why some browsers complain badly when
I consciously and manually enter a destination with an usual port
in exactly the same fashion as if a rogue server tries to coerce
a browser into connecting something unusual without the user
not having asked for it (or explicitly confirmed it).

When browsers fail to distinguish friend (end user) and foe (servers),
then it is a bug of the browser in combination with vulnerabilities
of the protocol between browsers and servers.  It definitely is not
a lack of a particular TLS extension, and it is pretty unlikely that
any number of TLS extensions are going to snake oil browser bugs or
the vulnerabilities in the server<->browser application protocols
go away,

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 20 Aug 2010 02:29:10 +1200

Martin Rex <[email-masked]> writes:

>When I'm at home (DSL ~2500/600), I can boost the rendering of pages by 2x
>using Adblock plus (Firefox).  And NoScripts give me some more performance
>back (but requires more "personal training" in distinguishing friend and
>foe). There's is likely no amount of additional(!) wrapping you could add
>with WebSockets+NPN that comes even close to that.

Similar results were reported by the HP folks who implemented outgoing
connection-throttling as a mean of combating malware, they found that web
pages loaded much faster because all the additional crap wasn't being pulled
in alongside the actual content.

Peter.

---

From: Marsh Ray <[email-masked]>
Date: Thu, 19 Aug 2010 10:02:14 -0500

On 08/19/2010 02:30 AM, Nathaniel W Filardo wrote:
> with C's production of Q.
>
> For concrete example, in the case of P=SMTP and Q=HTTP,
 > []

Lately I've been looking into a long-existing credentials forwarding 
attack on NTLM authentication. It's cross-protocol in the sense that the 
authentication can, in fact, be taken from an SMTP connection and used 
to authenticate an HTTPS session.

The slides pdf linked from there shows a grid of the explored and open 
attack space.

> everybody's satisfaction.

It seems plausible that the attacker might control enough data in the 
Client Hello, e.g. SNI, that it could be usefully interpreted by the 
server. Or more simply, just sending the random binary data would 
probably crash more than one server out there.

>    1. C has a client certificate which S will accept and S does not expect

I could imagine this happening, and without user intervention. Consider 
a corporate PKI scenario where every user and every server gets their 
cert from the same cert management system run by the IT dept.

>       credentials for C's use in this transmission.

A forwarding attack such as is possible with NTLM could potentially 
allow this.

> 2.

Well the idea of WebSockets is to give full-duplex communications to 
attacker supplied Javascript. If he can successfully complete the 
initial handshake, it's better to assume anything is possible after that.

> since it demonstrably has nothing to do with said functionality.

The TLS layer would seem to have a some of things going for it:

1. It's designed to authenticate-or-fail connections, i.e., it doesn't 
observe Postel's law.

2. Piggybacking on the TLS handshake could save a round trip.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Aug 2010 17:58:19 +0200 (MEST)

> of work that we are putting into it. (SPDY, Google DNS, Snap Start,

On my personal scorecard, management focus doesn't count as evidence
of much besides Hypes and succesful marketing.

TLS False Start has always been an obvious potential for optimization.
I haven't looked at Snap start yet, but I doubt that I would like it
after figuring out how it works.  To me it seemed that some mount of the
"apparent latency" is caused by TCP congestion control (TCP slow start
and delayed TCP ACK) and the original initial TLS roundtrip actually
improves opening of the transmit window.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Thu, 19 Aug 2010 12:00:45 -0500

> of much besides Hypes and succesful marketing.

I would go farther than that. I believe there have been cases of large 
companies adding complexity to interfaces in an attempt to put others at 
a relative disadvantage or even to kill an open standard by making it 
unimplementable.

However, I believe the authors of this proposal are sincere in their 
attempt to reduce overall latency by eliminating round trips.

> after figuring out how it works.

It appears to be quite complex and only usable in very specific 
scenarios, probably with API changes requiring extra logic in the 
application code. However, these narrow scenarios could account for 50% 
of TLS handshakes on the web.

As a developer though, it raises the question of if it's keeping with 
the spirit of a general "secure socket layer" communications primitive 
if it requires significantly more complex semantics than the traditional 
socket. Which implies that small-time apps don't compete on an equal 
footing. Especially if, say, Chrome and Android were the only clients 
that implemented it and Google were to arrange for such traffic to 
receive preferential treatment on certain networks.

> To me it seemed that some mount of the

There are other benefits to reducing round trips too.

Consider a network with bad statistical packet loss. The probability of 
failure of an overall transaction can increase exponentially with the 
number of packets required to complete it. Sure, TCP is supposed to 
retransmit, but we've all been on that bad wifi where you have to hit 
the reload button a few times before the web page comes up.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 19 Aug 2010 10:12:35 -0700

Marsh Ray wrote:
> 
> I believe there have been cases of large 

Yes, it is called "Embrace and Extend" and that has popped up on my radar
as well.  Google has stated its policy is "Don't be Evil" so I'm open to
other explanations but will remain skeptical.

Mike