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

Michael D'Errico <mike-list@pobox.com> Mon, 16 August 2010 17:42 UTC

Return-Path: <mike-list@pobox.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62113A686B for <tls@core3.amsl.com>; Mon, 16 Aug 2010 10:42:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzbdM4P+MlMv for <tls@core3.amsl.com>; Mon, 16 Aug 2010 10:42:37 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 960FD3A659C for <tls@ietf.org>; Mon, 16 Aug 2010 10:42:37 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id EC317CE691; Mon, 16 Aug 2010 13:43:12 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=flHBMkfi1qCj 5mnOyf00cdf9cZw=; b=vyvXODgWEr+lusqhatU1kKgNBgh4qKhrApf131TKwCgK SymJPf6ahc3YqU0tHUoaXfJXRO1pPsH1B1Ok0jF3Iefb1AXk2oTcQP13PKrYvX3j 6AqbuAN0fRGNe90NSr8zkkChFUSclQSGeP9jTe0s8WdiZzmkkf1wv4XP5hGYSmY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=g7ki8u R3Y26VU10LQni2Om7DFylkNjVhhN+Ux34IVxLOJfrQv+5/hiuTn5mwyP3QtV2Q4h hdOeFPfqTdI4VXtQBuAxXS1R4CNhtVaFcF/7lE9an1+HT6lleSC2ICEGRZk7Xn2Z za+SqgDFqL68tGVA6HiEQq/2sXxPIb73I/ujg=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 96927CE690; Mon, 16 Aug 2010 13:43:11 -0400 (EDT)
Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id C062CCE68D; Mon, 16 Aug 2010 13:43:09 -0400 (EDT)
Message-ID: <4C6978A3.1070404@pobox.com>
Date: Mon, 16 Aug 2010 10:42:59 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Adam Barth <ietf@adambarth.com>
References: <AANLkTi=5H_0hGzxMmfNU0hLS=5psW6J3c2to756OT--7@mail.gmail.com>
In-Reply-To: <AANLkTi=5H_0hGzxMmfNU0hLS=5psW6J3c2to756OT--7@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: BD2F9E28-A95D-11DF-9DB6-9056EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com
Cc: tls@ietf.org
Subject: Re: [TLS] Request for review: Next Protocol Negotiation Extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Mon, 16 Aug 2010 17:42:39 -0000

One problem is that the server is not made aware of the next protocol
until just before the Finished messages are exchanged.  By delaying
this information, the server can not use the protocol as part of its
certificate selection process.

I understand the desire to keep this information private, but it comes
with a cost.  If the server is handling many protocols and desires to
use different certificates for each because of different security
requirements such as lists of supported cipher suites per protocol, or
maybe they are hosting multiple virtual hosts and need to select the
proper certificate from a particular customer.

If the response to this is "use SNI" then you just leaked the information
you are trying to hide by delaying the next protocol until after CCS.

Mike




Adam Barth wrote:
> TLS experts,
> 
> As some of you may be aware, the HyBi working group is considering use
> a TLS extension has part of the WebSockets protocol [1].  I believe
> the extension has been mentioned on this list before, but as there is
> now renewed interested in its use, now might be a good time for this
> working group to look over the extension and provide feedback.
> 
> The extension, called Next Protocol Negotiation, adds information to
> the TLS handshake to let the client and server agree on which protocol
> they will speak over the encrypted tunnel once the handshake
> completes.  In some sense, this extension is to TLS what ports are to
> TCP: it allows multiplexing a number of protocols over a single
> listening endpoint (in the case of TLS, a TCP port, in the case of
> TCP, an IP address).
> 
> The HyBi working group is interested in Next Protocol Negotiation
> because it has two properties:
> 
> 1) It allows servers to multiplex HTTPS and WebSockets over the same
> listening port (typically 443).
> 2) After completing the TLS handshake (with the extension) both
> parties are guaranteed that the other party intends to speak
> WebSockets over the encrypted tunnel.  (This property is important to
> avoid cross-protocol vulnerabilities, which I can elaborate on if
> you're not familiar with that class of vulnerability.)
> 
> The current Internet-Draft is located here:
> 
> http://tools.ietf.org/html/draft-agl-tls-nextprotoneg
> 
> I look forward to receiving your feedback.
> 
> Kind regards,
> Adam
> 
> [1] http://trac.tools.ietf.org/wg/hybi/trac/ticket/14