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

[Adam Langley <[e-mail]>]

On Wed, Aug 18, 2010 at 12:13 PM, Adam Langley <[e-mail]> wrote:
> 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.

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