Re: [TLS] Server Signature Algorithms

Michael D'Errico <mike-list@pobox.com> Fri, 30 October 2009 03:15 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 487D73A6849 for <tls@core3.amsl.com>; Thu, 29 Oct 2009 20:15:35 -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 qd0V7djwBoTo for <tls@core3.amsl.com>; Thu, 29 Oct 2009 20:15:34 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 77FF83A679C for <tls@ietf.org>; Thu, 29 Oct 2009 20:15:34 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id D34A48BD63 for <tls@ietf.org>; Thu, 29 Oct 2009 23:15:50 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=GchSUd/ozNMc QS+e+34hLSt+aIE=; b=K+bwia+y7k7at7ttNJxTXAxcY6QDil2uRGfXiSs+Jmzz 8xUltk61BgeeHVeLVOemcGES0NJhINQOAUVN+UwWpRKom8NRWX5pn/975chZwfmf wHxcOaRs2/fuGulJJQ5tHcczD+kmZn8mvzq/PAZKTgT4Tc2sqJek7c06lX2MdZk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=pHJBN+ hTDzlHUMyDqtj/vn1+ozZ7POHyUD7GrEp9MQqlO9Pk/tWOjnqj12lE6atazKG6cW x+BJo0xQnXeOm6ThLDxb+eIkwNbLZ19kRYiJJy7ZPoXHWfirTfLfS5+6CnwSN69m X2OWNcP4Jtm6RfLk1rlO7rXhK2JaPjYLQcnr4=
Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id CFFF08BD62 for <tls@ietf.org>; Thu, 29 Oct 2009 23:15:50 -0400 (EDT)
Received: from administrators-macbook-pro.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-sd.pobox.com (Postfix) with ESMTPSA id 79FF98BD61 for <tls@ietf.org>; Thu, 29 Oct 2009 23:15:50 -0400 (EDT)
Message-ID: <4AEA5ABD.5040302@pobox.com>
Date: Thu, 29 Oct 2009 20:17:17 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: tls@ietf.org
References: <4AE9F0DE.7060903@pobox.com>
In-Reply-To: <4AE9F0DE.7060903@pobox.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 86B1917A-C502-11DE-BE9C-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com
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: Fri, 30 Oct 2009 03:15:35 -0000

If the existing signature algorithms extension is made symmetric, then
the server still will need to put the same list of algorithms in the
certificate request since it will not know whether the client knows
about the change.

Mike


I wrote:
> There are now at least 3 instances where a TLS client needs to know the
> server's list of supported signature algorithms:
> 
>    1. to compute the signature for the CertificateVerify message
>    2. to compute the hash of the handshake messages in (1) without
>       having to hold onto all of the messages
>    3. to compute hashes for the proposed cached information extension
> 
> Rather than duplicate the list for each of these and any future needs,
> it makes sense to send it once in a server hello extension.
> 
> The simplest option would be to use the existing signature algorithms
> extension and make it symmetrical.  But if there is a deployed client
> out there that aborts a connection if it receives a signature algorithm
> extension, then a secondary option would be to create a new server-
> signature-algorithms extension which is identical in structure to the
> existing extension.
> 
> I would add that when the server sends its list of algorithms in the
> extension, then it MUST NOT send a different list in the certificate
> request message; in fact it SHOULD send an empty list.  TLS 1.3 can
> decide whether to eliminate the list from CertificateRequest.
> 
> Mike