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

Adam Barth <ietf@adambarth.com> Tue, 17 August 2010 16:49 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715663A680D for <tls@core3.amsl.com>; Tue, 17 Aug 2010 09:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.745
X-Spam-Level:
X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WvCymVuxNWn for <tls@core3.amsl.com>; Tue, 17 Aug 2010 09:49:41 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 6E3F03A67FE for <tls@ietf.org>; Tue, 17 Aug 2010 09:49:41 -0700 (PDT)
Received: by wwi17 with SMTP id 17so1084359wwi.13 for <tls@ietf.org>; Tue, 17 Aug 2010 09:50:16 -0700 (PDT)
Received: by 10.227.157.4 with SMTP id z4mr5902739wbw.43.1282063816187; Tue, 17 Aug 2010 09:50:16 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id a1sm6655224wbb.2.2010.08.17.09.50.14 (version=SSLv3 cipher=RC4-MD5); Tue, 17 Aug 2010 09:50:15 -0700 (PDT)
Received: by pwi1 with SMTP id 1so8432pwi.31 for <tls@ietf.org>; Tue, 17 Aug 2010 09:50:13 -0700 (PDT)
Received: by 10.142.214.16 with SMTP id m16mr6072117wfg.5.1282063813575; Tue, 17 Aug 2010 09:50:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.60.18 with HTTP; Tue, 17 Aug 2010 09:49:52 -0700 (PDT)
In-Reply-To: <4C6AB936.1070801@extendedsubset.com>
References: <AANLkTi=5H_0hGzxMmfNU0hLS=5psW6J3c2to756OT--7@mail.gmail.com> <4C69938A.9080808@gnutls.org> <AANLkTin3eQHNJPuVuVw09FbPUF4RBk7n9RFbc7EaFbM+@mail.gmail.com> <AANLkTi=dfCZNndm678OFkCZdzRhzfmRvBmZVLUD5-ueF@mail.gmail.com> <4C6AB936.1070801@extendedsubset.com>
From: Adam Barth <ietf@adambarth.com>
Date: Tue, 17 Aug 2010 09:49:52 -0700
Message-ID: <AANLkTimgjqQMdwqL_xZXGSG5hSMLqDtYH62t698e_hx9@mail.gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [TLS] Request for review: Next Protocol Negotiation Extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Aug 2010 16:49:43 -0000

On Mon, Aug 16, 2010 at 6:33 PM, Martin Rex <mrex@sap.com> wrote:
> Michael D'Errico wrote:
>> 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.
>
> 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.

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

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

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.

On Mon, Aug 16, 2010 at 8:21 PM, Michael D'Errico <mike-list@pobox.com> wrote:
> Adam Barth wrote:
>> 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.
>
> 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.

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.

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

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.

On Mon, Aug 16, 2010 at 9:52 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 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.

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.

On Mon, Aug 16, 2010 at 10:28 PM, Michael D'Errico <mike-list@pobox.com> wrote:
> 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.

See above.

On Tue, Aug 17, 2010 at 7:01 AM, Martin Rex <mrex@sap.com> wrote:
> Geoffrey Keating wrote:
>> 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.
>
> 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.

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

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

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
<nmav@gnutls.org> wrote:
> On Mon, Aug 16, 2010 at 9:47 PM, Adam Langley <agl@google.com> wrote:
>>> Without getting on the details, why do that on the TLS protocol? This
>>> looks like something to be done on the application protocol.
>> 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?

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

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
> extend the IP protocol for what you want to achieve here, you
> 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.

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

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 <marsh@extendedsubset.com> wrote:
> 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).

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.

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

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