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

Brian Smith <> Sat, 20 August 2011 10:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 741C721F8744 for <>; Sat, 20 Aug 2011 03:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id glAN6HHyzHU1 for <>; Sat, 20 Aug 2011 03:45:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1180D21F871C for <>; Sat, 20 Aug 2011 03:45:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 25BF8AE647B0; Sat, 20 Aug 2011 03:46:04 -0700 (PDT)
Date: Sat, 20 Aug 2011 03:46:04 -0700 (PDT)
From: Brian Smith <>
To: Eric Rescorla <>
Message-ID: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
X-Mailer: Zimbra 6.0.8_GA_2661 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661)
Subject: Re: [TLS] Review of draft-agl-tls-nextproto-00
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 20 Aug 2011 10:45:05 -0000

Eric Rescorla wrote:
> It's unclear from the draft what the motivation for this work is.

Practically, it allows multiple protocols to be offered on the same host:port. In particular, it allows SPDY and HTTP to both use port 443. Mozilla will use this extension (or the previous version) for exactly this purpose. In addition, I think we will also eventually use it for all of our TLS-based communication, to reduce the risk of cross-protocol attacks.

> 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?

SMTP, HTTP, IMAP, WebSockets. (There are email providers that offer IMAPS and SMTPS over port 443.)

> 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:


> 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.

We should not send data unprotected when we can send it protected. I think this is a more important design goal.

We could generalize the mechanism so that the new message consists of a sequence of TLS extensions, to avoid creating new message types in the future.