Re: [TLS] Server Signature Algorithms

Wan-Teh Chang <wtc@google.com> Mon, 02 November 2009 18:02 UTC

Return-Path: <wtc@google.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 3EE643A6A55 for <tls@core3.amsl.com>; Mon, 2 Nov 2009 10:02:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 uF0iXZ0vue-6 for <tls@core3.amsl.com>; Mon, 2 Nov 2009 10:02:28 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 400D43A6A51 for <tls@ietf.org>; Mon, 2 Nov 2009 10:02:28 -0800 (PST)
Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id nA2I2j8m002678 for <tls@ietf.org>; Mon, 2 Nov 2009 18:02:45 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257184967; bh=PqjVPO5aGqG9+fK8MhGxJNZqSxc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ceB+OysO0Uwd6WFq+p6n3VBcF8h7WVBSorSji4cZfvwW2Rtvkr9o8qV9VDjHJVU7P hi/mI6q5Y96qJDIdNBt5Q==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=cXxLm7FIJsFuIoc7fC6T8kIOQ2hLu4K+efEa0MLUNu/17vbNk2Yb6NKJKdFR0fsqu U2hwM+Jqnyp1NiGXpL64A==
Received: from pzk35 (pzk35.prod.google.com [10.243.19.163]) by zps76.corp.google.com with ESMTP id nA2I2LuJ000919 for <tls@ietf.org>; Mon, 2 Nov 2009 10:02:42 -0800
Received: by pzk35 with SMTP id 35so3540848pzk.22 for <tls@ietf.org>; Mon, 02 Nov 2009 10:02:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.25.19 with SMTP id c19mr888148wfj.87.1257184961629; Mon, 02 Nov 2009 10:02:41 -0800 (PST)
In-Reply-To: <4AEDFED0.7060505@pobox.com>
References: <OFCFFB440A.DEB1CEA7-ON4A257661.007208C6-4A257661.007271E8@au1.ibm.com> <4AEDFED0.7060505@pobox.com>
Date: Mon, 02 Nov 2009 10:02:41 -0800
Message-ID: <e8c553a60911021002p504049feqfa2da5b154e66c9@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: Michael D'Errico <mike-list@pobox.com>, Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: tls@ietf.org
Subject: Re: [TLS] Server Signature Algorithms
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, 02 Nov 2009 18:02:29 -0000

On Sun, Nov 1, 2009 at 1:34 PM, Michael D'Errico <mike-list@pobox.com> wrote:
> So instead of changing the existing signature_algorithms extension,
> nothing would break by creating a new server_signature_algorithms
> extension.  Client support would be advertised by sending an empty
> extension to the server.  The server would show support by replying
> with its list.

Michael: I agree this would be the safest solution which
eliminates the concern of breaking some TLS 1.2 implementation,
at the cost of adding a new TLS extension.

This would be an example of a "server-oriented" extension
described in Sec. 2.3, page 7 of RFC 4366.

Nikos: GnuTLS is one of the first TLS 1.2 implementations.
How does GnuTLS deal with this issue now?  Does it compute
hashes of all the hash algorithms it supports on the handshake
messages, or does it buffer the handshake messages until
the hash algorithm has been selected?

Wan-Teh