Subject: [TLS] Next protocol negotiation

From: Adam Langley <[email-masked]>
Date: Wed, 20 Jan 2010 05:20:20 -0800

(This email is the 'cover letter' for
http://www.ietf.org/internet-drafts/draft-agl-tls-nextprotoneg-00.txt,
which had been waiting for the renegotiation issue to die down a
little.)

The reaction to the announcement of SPDY[1] (a new presentation layer
for HTTP) has been surprisingly positive, except for our choice to use
TLS. Correspondents have suggested that TLS is slow, expensive,
troublesome to administer and unnecessary. We disagree on these points
and have tried to correct misunderstandings and out of date
information where we have found them.

But we have found that people are generally unaware of one of the
central reasons for using TLS: there is no other choice for new
protocols.

For our development of WebSockets for WebKit (and, thus, Chrome and
Safari) we setup an experiment to find out how many hosts on the
Internet could setup a WebSockets connection. (WebSockets uses an HTTP
Upgrade header over port 80 or 443).

The experiment tries to perform a trival WebSockets transaction over
HTTP, over HTTP on a random, high numbered port (61985) and over
HTTPS. This experiment is run via Chrome for users who have opted in.
These are normal requests in the Chrome network stack and so will use
any configured proxies.

Excluding users that couldn't even do basic a HTTP transaction over
the transport layer (6.37%, 10.15% and 7.91%, respectively), the
success rates are:
    HTTP (port 80)      67%
    HTTP (port 61985)   86%
    HTTPS (port 443)    95%

This results in overall sucess rates of 63%, 77% and 87%, respectively.

I stress that these results are preliminary. In time we want a larger
sample size and to better understand the various failure cases. We
would also like to point out that there is a strong preselection bias
in effect here. We believe that Chrome is likely to be
underrepresented on networks with strong central control. We also
believe that those networks are more likely to contain pertinent
middleware. The true success rate over HTTP in the real world could be
less than 50%.

Even at this early stage, it's clear that TLS over port 443 is by far
the best transport for a new protocol. Since we have lost TCP port
numbers as a means of protocol disambiguation we added another
mechanism into the TLS handshake. This is described in the
accompanying draft.

Alternatives:

We considered several alternatives to this design.

We could have wrapped the first request in an HTTP presentation.
Base64 encoding and the HTTP headers increase the size of the request.
Later disambiguation makes the server side code less modular. Lastly,
it simply strikes one as the wrong thing to do; admiting defeat and
accepting an accumulation of protocol detritus.

We could have had the client advertise a list of protocols in the
ClientHello and had the server select one in the ServerHello. Instead
we moved the final protocol selection under the cover of the secure
transport. Although this is probably not needed in our case, we intend
this mechanism to be generally useful. Without this protection, we
fear that network middleware might use the protocol selection to
discriminate against certain protocols. For example, a by dropping all
TCP connections that tried to negotiate the "tor" protocol.

We could also have moved the NextProtocol handshake message after the
Finished message. At the time we didn't because the NextProtocol is
needed before reading the first bytes from the connection and the
processing of the Finished message triggers handshake complete
callbacks in the TLS libraries that we are working with.

After having implemented this several times we are less concerned
about these code changes. We consider moving NextProtocol after the
Finished message to be perfectly reasonable and have no strong
opinions either way.

Currently unspecified behaviour:

Several aspects of the design have been deliberatly omitted from the
draft because we didn't want to pin them down at this point. These
include the behaviour of the parties when it comes to protocol
selection.

Our current code follows this algorithm:

Let the client and server know an ordered set of protocols, where a
protocol is a non-empty byte string less than 256 bytes long. The
client's set must be non-empty.

A protocol is serialised by prepending a 8-bit length. An ordered set
of protocols is serialised by serialising each element in order.

The server includes its (possibly empty) set in the ServerHello.

If the set is empty, the client selects the first protocol in its set
(case A). Otherwise, the client finds the first of the server's
protocols that is included in its own set. If such a protocol exists,
the client selects it (case B). If no such protocol exists, the client
selects the first protocol in its list (case C).

The selected protocol is sent in the NextProtocol message.

The client's TLS library returns the selected protocol and the case
(A, B or C) that resulted.

This allows the server to pick the most preferable protocol if the
client and server mutually support several. It also allows the client
to force the selection of a certain protocol, even if the server
doesn't advertise it by only including a single protocol in its set.
(An example would be a Tor client, assuming that Tor servers would
want to advertise something more common, like HTTP.)

Although this behaviour is important, we are still experimenting and
so we have not yet included this in the draft.

Assignment of protocols:

Should this be adopted, a registry of protocols may be worthwhile to
prevent multiple protocol byte strings for the same protocol. Since
the code space is so large, this registry can afford to have very low
requirements. It need only reflect reality.

At the present time, we are using two protocols:

68747470312e31	HTTP 1.1 (RFC 2616)
73706479	Experimental (SPDY)

Implementations:

We have client and server implementations for OpenSSL and a client
implementation for NSS. Both available on request.

Cheers

AGL

[1] http://www.chromium.org/spdy
[2] http://dev.w3.org/html5/websockets/

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 20 Jan 2010 15:46:56 +0100

> which had been waiting for the renegotiation issue to die down a
[...]
> Upgrade header over port 80 or 443).

I was wondering, why not do it the other way round. I mean why not
upgrade to TLS from
websockets using the rfc2817 method (Upgrading to TLS Within
HTTP/1.1), or similar. Wouldn't
that solve the need for a new TLS extension?

best regards,
Nikos

---

From: Adam Langley <[email-masked]>
Date: Wed, 20 Jan 2010 07:05:55 -0800

> that solve the need for a new TLS extension?

For WebSockets, the answer seems pretty clear: one should use HTTPS
URLs. In that case, the protocol to use is communicated before hand.
The WebSockets protocol is designed to look like an HTTP Upgrade to
HTTP servers[1].

My email might not have been too clear, but the problem that we have
is that we wish to negotiate SPDY[2] (not WebSockets). There are also
other protocols that want to use TLS over port 443 (Tor is one that
I'm most familiar with).

Using HTTP Upgrade is a possibility for this, as discussed:

"We could have wrapped the first request in an HTTP presentation.
Base64 encoding and the HTTP headers increase the size of the request.
Later disambiguation also makes the server side code less modular. Lastly,
it simply strikes one as the wrong thing to do; admiting defeat and
accepting an accumulation of protocol detritus."

AGL

[1] http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-68
[2] http://www.chromium.org/spdy

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 20 Jan 2010 16:39:17 +0100

[...]
> accepting an accumulation of protocol detritus."

Ok now I see your point. However I still suggest solving issues at the
appropriate layer, even that has some performance cost. Consider the
case where applications add extensions to TCP. In the long term I
believe it pays off by having a simple security provider protocol and
simple applications that implement it. (not that today's TLS is that
simple - and there are already some application specific extensions).

best regards,
Nikos

---

From: Adam Langley <[email-masked]>
Date: Wed, 20 Jan 2010 07:57:31 -0800

On Wed, Jan 20, 2010 at 7:39 AM, Nikos Mavrogiannopoulos
<[email-masked]> wrote:
> appropriate layer, even that has some performance cost.

The appropriate layer for protocol disambiguation is TCP.
Unfortunately, this mechanism has stopped functioning for practical
purposes and we're aware that we aren't the only group facing this
problem.

Burning an additional round trip on protocol discovery is unacceptable
for us[1]. 200ms is a good round-trip time on a 3G network and the
nature of web content means that progressive discovery of additional
resources amplifies this delay.

Also, consider that without a suitable mechanism, we might be
condemning future protocols to forever limiting their initial
handshake to something that is HTTP compatible. We (Google) don't mind
putting in the work to make more fundamental changes but others,
perhaps, would choose not to for reasons of expediency, and would pay
this technical debt forever more.

[1] http://googleblog.blogspot.com/2009/06/lets-make-web-faster.html

AGL

---

From: Marsh Ray <[email-masked]>
Date: Wed, 20 Jan 2010 10:26:14 -0600

> purposes and we're aware that we aren't the only group facing this

One point of view is that firewall admins are ports because of their
intentional policies and it is their right to control what goes on on
their own network. Port 443 is going to be less useful over time as more
sites deploy SSL-inspecting proxies.

I don't particularly like that point of view, but it does seem to be the
reality. So we have a situation where people desiring to make a new
simple, secure protocol have to smuggle their traffic (even outbound
connections) like some kind of malware.

Once we're honest about what we're doing, other options might be available:

Port 443 to a proxy server with the CONNECT verb usually works.

It is rumored that many firewalls will pass anything over port 53.

On many corporate Windows PCs, the 'proxy server' info available in the
registry is the only reliable way to make outbound connections.

> handshake to something that is HTTP compatible.

You might also be able to use HTTPS to tunnel to an appropriate proxy.

> We (Google) don't mind

Thank you guys for caring about 200ms of my finite lifetime.

- Marsh

---

From: Steve Dispensa <[email-masked]>
Date: Wed, 20 Jan 2010 10:30:54 -0600

On 1/20/10 10:26 AM, "Marsh Ray" <[email-masked]> wrote:
> their own network.

That's giving many administrators too much credit; the new WizBang
FireScannerProxyWallThingy(TM) is configured to automatically block anything
and everything, because that's what WizBang's coders read was best practice
in the latest Gartner report, and the administrator is only dimly aware of
what's really going on. He just knows he can check the box on this year's
SAS-70 audit.

Surely you're right some of the time, but I suspect stuff gets automatically
blocked more often than not.

 -Steve

---

From: Adam Langley <[email-masked]>
Date: Wed, 20 Jan 2010 08:52:32 -0800

> sites deploy SSL-inspecting proxies.

Organisations that deploy intercepting proxies and port blocking
middleware (etc) have reasonable policy goals that they are trying to
implement. These people, for the most part, are not bad nor evil.

But one cannot expect them to understand the value of the end-to-end
principle. They are evaluating different solutions and balancing cost
and utility, as it effects them. It turns out that many of them end up
choosing networking hardware for caching, virus-scanning, content
control etc.

These network based solutions can be cheap, but they achieve these
cost reductions, in part, by imposing negative externalities on the
rest of the world. It's the case these days that HTTP traffic will
usually be 'transparently' intercepted at least once. DNS traffic is
likewise adulterated, as are many other protocols. Because of this,
protocol advances are delayed or lost. (HTTP pipelining is one
example, there are many others including our own SDCH[1]).
Unfortunately, these losses to the world are non-obvious to many and
hard to measure.

TLS is attractive because it is obviously much more resistant to these
machinations. (I'm aware that such devices do exist to intercept SSL,
but they should hopefully be intrinsically more limited.)

I admit that by using TLS we are bypassing (preferably) these
middleware boxes. Because of this, the cost/benefit analysis of these
boxes will hopefully shift so that people start to look for other
solutions. We know that we'll have to provide alternatives, but these
can be designed so as not to consign the public Internet to slow
stagnation at the bottom of the protocol stack.

[1] http://en.oreilly.com/velocity2008/public/schedule/detail/2598

> registry is the only reliable way to make outbound connections.

Port 53 is not as clean as one might hope. CONNECT and port 443 often
works, but then we have the same issue as we currently face: how to
disambiguate protocols when the TCP port mechanism is unavailable.
Next protocol negotiation is our proposed solution.

> Thank you guys for caring about 200ms of my finite lifetime.

You're welcome although, as noted, the actual delay usually ends up
being several multiples for web pages as subresource discovery is
slowed down for other domains.

AGL

---

From: Marsh Ray <[email-masked]>
Date: Wed, 20 Jan 2010 10:54:32 -0600

> what's really going on. He just knows he can check the box on this year's

That's an intentional policy which is their right to set (whether it's a
good one or not).

> blocked more often than not.

Blocking outbound connections based on destination port number is
particularly stupid since it's a parameter trivially controlled by an
attacker.

It's more a tactic to discourage people within the organization from
using new protocols. Malware won't have any problems though.

There will never be a clean and standardized way to get around firewalls
that are trying to block you. Once a technique shows up on the radar,
sooner or later it will get subjected to policy. The radar seems to get
faster over time, too.

For a high-profile company like Google to develop a new transport for
the web, the best method might very well be to just get a proper port
number allocation and make the protocol useful and secure enough that
admins actually let it thorough. One thing that might help would be to
make it easy for filtering proxies to inspect.

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Jan 2010 07:51:57 +0200

> using new protocols. Malware won't have any problems though.

That's right. The standard policy for firewalls these days, is to allow only ports 80+443 for the general population (The SMTP and DNS servers get to do more).
Port 80 gets deep inspected to see that it's standard WEB (with different products having different interpretations of "WEB" - some of them block Skype, others don't) and port 443 gets inspected for "looking like SSL", meaning handshake and application data records with reasonable lengths. This kind of policy can still work at line speed on modern hardware, and is very popular with auditors. It has the advantage that it is successful in blocking bandwidth wasters like file sharing, and the better product allow the administrator to configure whether to allow various peer2peer applications like Skype, GTalk or Messenger.

> sooner or later it will get subjected to policy. The radar seems to get

Thanks. We try.  :-)

> make it easy for filtering proxies to inspect.

Google may seem high-profile, but even Microsoft, which is even more high-profile had to resort to the "everything over the web ports" for messenger.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Jan 2010 08:00:03 +0200

> but they should hopefully be intrinsically more limited.)

Currently, it is, but processing power is cheap and getting cheaper.

> solutions.

Actually, I think this will shift the cost/benefit analysis of the SSL-inspecting proxies.  As more applications move to the "all the Internet over port HTTPS" paradigm, the administrators will have more incentive to deploy these proxies. If policy says that all files sent to people in other companies needs to be scanned by the data leakage prevention software, and some application like Skype sends files to your contacts over port 443, then you need something to look into the SSL. So I agree with Marsh - the proxy will become more common with time.

> We know that we'll have to provide alternatives, but these

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Jan 2010 10:07:31 +0200

> This results in overall sucess rates of 63%, 77% and 87%, respectively.

That HTTPS number is very surprising. It suggests that 5% of Chrome users can do regular HTTPS, but not WebSockets over HTTPS?

Are SSL-inspecting proxies that prevalent?

Maybe this suggests that Chrome's bias is FOR tightly-controlled environments rather than AGAINST.

---

From: Marsh Ray <[email-masked]>
Date: Thu, 21 Jan 2010 02:19:22 -0600

Yoav Nir wrote:
>> TLS is attractive because it is obviously much more resistant to
>> these machinations. (I'm aware that such devices do exist to
>> intercept SSL, but they should hopefully be intrinsically more
>> limited.)
> 

I wonder if the 'channel bindings' work will end up throwing a monkey
wrench in this. Will the SSL proxy be required to know all the secrets
of the higher-level protocols in order to terminate the SSL?

>> middleware boxes.

Who wouldn't want to? Do they provide any value-add to the exchange of
data (legitimate or otherwise)?

>> Because of this, the cost/benefit analysis of
>> these boxes will hopefully shift so that people start to look for
>> other solutions.
> 
> Actually, I think this will shift the cost/benefit analysis of the
> SSL-inspecting proxies.  As more applications move to the "all the
> Internet over port HTTPS" paradigm,

1. Doesn't this represent to some degree a failure of the basic TCP/UDP
address+port model (or perhaps it is being outgrown)? Maybe packet
headers are just no longer sufficient for making the block vs. route
decisions.

2. If this is true, what depth of inspection is necessary to provide
security? Is it destined to grow ever deeper? Semantic web indeed!

3. This is a fascinating discussion.

> the administrators will have more
> incentive to deploy these proxies. If policy says that all files sent
> to people in other companies needs to be scanned by the data leakage
> prevention software, and some application like Skype sends files to
> your contacts over port 443, then you need something to look into the
> SSL. So I agree with Marsh - the proxy will become more common with
> time.
> 
>> We know that we'll have to provide alternatives, but these can be
>> designed so as not to consign the public Internet to slow 

So if one wants to define a new protocol and have it routable over the
21st century internet, it needs to either:

1. Appear indistinguishable from innocuous web surfing over HTTP/HTTPS.

or

2. Explicitly support inspection in its design. It would have to be so
amenable to inspection that firewall vendors recommend that it be
allowed as a more secure alternative to HTTP. This is impossible in the
general case, but it would be possible to support actual data type
checking in the protocol. Something similar to having a list of allowed
XML schemata against which requests and responses are validated.

What do you all think of this?

- Marsh

---

From: Adam Langley <[email-masked]>
Date: Thu, 21 Jan 2010 03:04:11 -0800

> Maybe this suggests that Chrome's bias is FOR tightly-controlled environments rather than AGAINST.

As noted, this data is preliminary but I will make some guesses:

The nature of the test is that it proceeds in steps, each step testing
some behaviour of the WebSockets protocol. If the user closes the
browser during the process, this can appear the same as a protocol
failure.

The breakdown of the failure rates at each step with TLS looks very
different from the HTTP patterns. With HTTP we see clear jumps where
the network is opaque to some behaviour for a significant fraction of
our users. The TLS data increases nearly linearly in comparison. Thus
it might well be that we're just seeing noise in the TLS data as the
steps proceed over time. I don't believe that TLS intercepting proxies
are actually deployed in front of 5% of our users.

We obviously want to investigate this ourselves and we're continuing
with our analysis and data gathering.

AGL

---

From: Adam Langley <[email-masked]>
Date: Thu, 21 Jan 2010 08:49:29 -0800

> security? Is it destined to grow ever deeper? Semantic web indeed!

Inspection of network traffic, even if TLS connections are unwrapped,
cannot stop a determined attacker. There will always be large amounts
of side channel capacity in anything resembling a web capable
connection.

But I don't believe that this is the threat model of these middleware
boxes. In my experience they generally want to implement caching,
virus scanning or blocking of casual users. The caching issue is an
interesting one and we welcome development in this area. But these
must be implemented in a manner that doesn't result in the continual
ossification of the Internet. By being implicit and undocumented they
force a continuous retreat to the least common denominator in the hope
most of them will pass simple traffic most of the time. This probably
means that the network is not the place for them and that one should
focus on client side changes and explicit configuration of proxy
servers.

The development of TLS intercepting proxies is saddening. Thankfully I
believe that they are currently fairly limited. In the interests of
future development, measures should probably be taken to ensure that
they remain so. (In this point I am not representing my employer: to
my knowledge we've no official position on this.) For example, Chrome
could require that certificates for Google sites always be rooted at
Thawte for the lifetime of the current certificates. When considering
various issues with the CA ecosystem in the past couple of years, this
might also have a desirable security benefit.

AGL

---

From: Dean Anderson <[email-masked]>
Date: Thu, 21 Jan 2010 14:22:45 -0500 (EST)

Adam, 

You do realize that using TLS as a base protocol requirement increases
the computational and operational costs, prohibits http named virtual
hosts, and probably other things.  Whatever you save in the first trip
is burned in the encryption/decryption later.  I think the goal of
improving connection negotiation speed is good in general, but I don't
think that using TLS is going to help other protocols connect faster.  
TLS has its own issues connecting fast (better than it was, but security
is more important---connection speed would be sacrificed for security at
the TLS layer).  And then you still have to negotiate the application
protocol, anyway.  If the application layer is progressive and slow, TLS
isn't going to change that.

Second, I don't think protocols should be designed with too much
emphasis on existing middleware boxes. These boxes will change as their
users' needs change.  As was noted, the goals of these boses are not
inherently evil, but are a tradeoff with the goals of protocol design,
and particularly fast negotiation and other needs the protocol probably
can't anticipate (this is layering, and is 'good'). A metaphor that
comes to mind is the tradeoff made at the airport between fast boarding
and security screening.  One designs aircraft and aircraft boarding
areas with one primary goal. But terminals one must accomodate the other
goals, (eg. security, parking, ground transportation, etc) too.

Third, my initial impression of the CONNECT scenario reminds me of the
old VTAM and 3270 terminals connecting to applications.  Perhaps we
should keep looking...or maybe we should reconsider VTAM or APPC... ;-)

		--Dean

On Wed, 20 Jan 2010, Adam Langley wrote:

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

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494

---

From: Adam Langley <[email-masked]>
Date: Thu, 21 Jan 2010 11:40:15 -0800

On Thu, Jan 21, 2010 at 11:22 AM, Dean Anderson <[email-masked]> wrote:
> hosts, and probably other things.

I believe the point about named virtual hosting to be incorrect. I
don't know of any cases where SNI doesn't solve this.

(The level of support for SNI in the browser fleet isn't good. I have
numbers from our HTTPS servers but I've never asked to clear them for
public release. However, for new protocols this isn't an issue since
we require SNI support from our clients from the outset.)

I also don't feel that the computational overhead of encryption + MAC
is significant. You're welcome to look at
http://bench.cr.yp.to/results-stream.html for the numbers, but it ends
up being a judgement call in the end. Either way, wherever you fall on
the line, it becomes less of an issue each year.

The latency impact of TLS, of course, is significant and we're working
on more aspects of TLS than just this draft to reduce this.

> goals, (eg. security, parking, ground transportation, etc) too.

You're welcome to consider the draft on its merits irrespective of
this argument. I think it still stands.

Cheers

AGL

---

From: Dean Anderson <[email-masked]>
Date: Thu, 21 Jan 2010 16:51:27 -0500 (EST)

> don't know of any cases where SNI doesn't solve this.

That's a good point. 

> the line, it becomes less of an issue each year.

I don't think so. As CPU's speed up improving encryption/decryption
times, so does cracking improve, resulting in deployment of more
difficult ciphers, leaving time to encrypt roughly unchanged.  So I
don't think encryption gets "easier" or less time-consuming in the
future. Again, an impression, but consider that the RSA-768 key was just
cracked, and so we recommend getting rid of 1024 bit keys. And e.g some
interesting results were published for AES-256, suggesting it will be
easier to crack than originally anticipated, meaning it will be obsolete
sooner.  

> > users' needs change. Â As was noted, the goals of these boses are not
> > and security screening. Â One designs aircraft and aircraft boarding

It could be---Just my first impressions.  By all means, keep working the
problem.  Just keep an open mind that this path might be a dry hole.

Sometimes, as like DNSSEC, people become married and financially
invested in a scheme that can't work. In the worst case, they ignore the
problems and silence the critics.  But eventually, the facts always come
out.

http://lists.iadl.org/pipermail/namedroppers-honest/2010-January/000074.html

		--Dean

---

From: Adam Langley <[email-masked]>
Date: Fri, 22 Jan 2010 03:03:30 -0800

On Thu, Jan 21, 2010 at 1:51 PM, Dean Anderson <[email-masked]> wrote:
> cracked, and so we recommend getting rid of 1024 bit keys.

Clients get the easy side of the RSA operations of course. If we take
four different hosts from the ECRYPT benchmarks[1] we can get the
number of cycles required to perform an RSA encryption of a given bit
size:

1024    203820  171138  79404   302432
1536    317448  260392  117587  519928
2048    470556  386199  157766  779696
3072    866280  704583  271095  1604108
4096    1396896 1067935 387822  2423856

(CPUs are, in order, Atom (molecule), Core2 (nmui0247), A64 X2 (mace),
Power5 (nmi0154))

Normalising each of these so that the time taken for 1024 is 1:

1024    1       1       1       1
1536    1.557   1.522   1.481   1.719
2048    2.309   2.257   1.987   2.578
3072    4.250   4.117   3.414   5.304
4096    6.854   6.240   4.884   8.015

However, from the 768-bit factoring paper[2] they suggest that a
1024-bit key is 5x harder to factor than a 768-bit key, for only a
1.3x increase in the number of bits. So it appears the that defender
has the advantage as processor speeds increase (modulo quantum
factoring, should it ever be tractable).

[1] http://bench.cr.yp.to/results-encrypt.html
[2] http://eprint.iacr.org/2010/006.pdf

> And e.g some

You can repeat the procedure above for stream ciphers too. Again, the
defenders appear to have the advantage over time.

AGL