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

"Brian Smith" <brian@briansmith.org> Mon, 16 August 2010 18:30 UTC

Return-Path: <brian@briansmith.org>
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 9682E3A682D for <tls@core3.amsl.com>; Mon, 16 Aug 2010 11:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.754
X-Spam-Level:
X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=0.845, 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 Yo6Q5sTlRSuh for <tls@core3.amsl.com>; Mon, 16 Aug 2010 11:30:21 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 671D93A6A4C for <tls@ietf.org>; Mon, 16 Aug 2010 11:30:20 -0700 (PDT)
Received: from T60 (unknown [98.200.150.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D9183509E1; Mon, 16 Aug 2010 14:30:49 -0400 (EDT)
From: Brian Smith <brian@briansmith.org>
To: 'Michael D'Errico' <mike-list@pobox.com>
References: <AANLkTi=5H_0hGzxMmfNU0hLS=5psW6J3c2to756OT--7@mail.gmail.com> <4C6978A3.1070404@pobox.com>
In-Reply-To: <4C6978A3.1070404@pobox.com>
Date: Mon, 16 Aug 2010 13:30:48 -0500
Message-ID: <001301cb3d71$295b28f0$7c117ad0$@briansmith.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGWKjOVVsWlkADqERmWe4yahRG/kwDZIqNxAQ7X3n4=
Content-Language: en-us
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 18:30:23 -0000

Michael D'Errico wrote:
> One problem is that the server is not made aware of the next protocol
until just
> before the Finished messages are exchanged. 

Wouldn't it actually be better to put the next protocol message *after* the
Finished message so that it can be protected with a HMAC instead of a HMAC
of a PRF'd hash?

> By delaying this information, the server cannot 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.

SNI was created because the certificate contains the hostname, and the
server needs to choose the certificate based on the hostname. Since the
certificate doesn't contain the protocol, the server doesn't need to choose
the certificate based on the protocol in use. Choosing the cipher suite
based on the protocol doesn't seem very useful and doesn't fit with the TLS
design; the server is supposed to choose the best cipher suite that both
sides support. Also, current implementations already provide support for
switching the cipher suite based on information that they receive after CCS
via renegotiation. For example, Apache will start a renegotiation if the
request URL maps to a resource that has been (mis)configured to use a cipher
suite different than the default for the server.

Cheers,
Brian