[TLS] Review of draft-agl-tls-nextproto-00

[Eric Rescorla <[e-mail]>]

This document describes a mechanism whereby a TLS client and
server can agree about the "next" protocol, i.e., the protocol
which will be carried over TLS.


MOTIVATION
It's unclear from the draft what the motivation for this work is.
Section 1 says that NPN is for preventing cross-protocol attacks,
specifically citing WebSockets:

   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, the Next
   Protocol extension described in this document extends the TLS
   [RFC5246] handshake to allow the client to tell the server the
   intended application protocol.

However, WebSockets does not use NPN; the HyBi working group
explicitly rejected NPN because it would have required the use of TLS
at all times. I'm not saying I agree with this, but it's what
happened.  Instead, the HyBi WG designed their own application-layer
handshake which is intended to thwart cross-protocol
attacks. Similarly, the other major WG which is currently concerned
with cross-protocol attacks, WebRTC, is not interested in NPN but
rather is using an ICE-based handshake prior to sending traffic. What
IETF protocols have a demand for this functionality?


ENCRYPTED NEGOTIATION
This document specifies a partially encrypted negotiation mechanism:
the server advertises some set of protocols (in the ServerHello)
and the client specifies a specific protocol (in a separate
handshake message inserted between the CCS and the Finished).
The client's announcement need not match any of the protocols
specified by the server. Thus, the negotiation is partly encrypted.

The reason for this appears to be that this mechanism is designed to
prevent network attackers from learning which next protocol is being
requested. (See Section 4). I'm extremely skeptical of this objective:
Avoiding this kind of application identification has not traditionally
been a TLS design goal. Indeed, TLS has features which make this
problematic, such as unpadded records (in stream cipher modes) and
application types in the extended key usage. People who operate DPI
boxes will generally be able to identify the relevant applications and
block them. Moreover, for applications which do not require TLS client
authentication, it's generally easy to determine what the server runs
by simply connecting to it (in general, most TLS endpoints run only a
small number of protocols) and then block as appropriate. If this sort
of evasion becomes a TLS design goal, much more work will be
necessary.

This wouldn't be a big deal except that this highly imperfect
functionality comes at significant architectural cost. This mechanism
is clearly more  invasive and complicated than necessary to accomplish the
goal of addressing cross-protocol attacks. That objective could easily
be met by having the client announce in an extension the protocol he
wishes and the server either accept or reject immediately (prior to
the key exchange stage). This would also be far clearer from a
layering perspective, as it would conceptually match the use and
timing of the TCP port number, just pushing it a few bytes over into
the TLS ClientHello. Moreover, it is extremely odd to have the server
advertise a list of protocols which does not match the list which it
is actually willing to use. For that matter, it's not even clear what
the point of the advertisement is in most cases since, again, most
servers run only one protocol and a 16-bit port number is clearly far
too crude for version negotiation.