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