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

Eric Rescorla <ekr@rtfm.com> Thu, 28 July 2011 17:13 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6CB5E8014 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 10:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rvjSqrkp9QL for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 10:13:39 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F42085E800D for <tls@ietf.org>; Thu, 28 Jul 2011 10:13:38 -0700 (PDT)
Received: by wyj26 with SMTP id 26so12948wyj.31 for <tls@ietf.org>; Thu, 28 Jul 2011 10:13:38 -0700 (PDT)
Received: by 10.227.200.210 with SMTP id ex18mr347953wbb.7.1311873218080; Thu, 28 Jul 2011 10:13:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.145.209 with HTTP; Thu, 28 Jul 2011 10:13:18 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 28 Jul 2011 13:13:18 -0400
Message-ID: <CABcZeBMvyOmTYKeG9odE_QoHjTYrUOZegmW6+FsBzj42+dbKQg@mail.gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [TLS] Review of draft-agl-tls-nextproto-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Thu, 28 Jul 2011 17:13:39 -0000

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.