[TLS] Server Signature Algorithms

Michael D'Errico <mike-list@pobox.com> Thu, 29 October 2009 19:43 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 2BA323A6A0D for <tls@core3.amsl.com>; Thu, 29 Oct 2009 12:43:57 -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 fs6dZ1+DwfSY for <tls@core3.amsl.com>; Thu, 29 Oct 2009 12:43:56 -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 5F2723A68FF for <tls@ietf.org>; Thu, 29 Oct 2009 12:43:55 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 03A9E8A9E1 for <tls@ietf.org>; Thu, 29 Oct 2009 15:44:11 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=Taymgw17NjheI+nRdbSS2ndW2 2Q=; b=kJlUThw6B8A/0TrZPGPP+0HkRNRbu/c7f6ZMBzKvUDm6dOR8eH5iRfAkz e9eDcE68uD4JdJ+3MrodiJ/C6V5PWuZrUwDN2dtxp90coqilQceE6tRvmbGp/Xac j2k1RPMEQibJ/ipyuBRJpFhdgmp+E+A5/1ks6pVmRfPFP9cOk4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=Xi4RNK4DHxf9XOT0Ycg JrmVEcH2Glz8k2br/lcnaH/xgnbU+Io9JtJFWMD1I+kE6KyKovLJ2mJmE36BODyw X6Kq5lbHIGLs0viCsfgvEOC/Yye48OKVFeLISSjlUovmUXshk8JywkXCbr9OcX4E 5Vu4MtrU0t1X28wDNVCFhSGY=
Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 00D5B8A9E0 for <tls@ietf.org>; Thu, 29 Oct 2009 15:44:10 -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 79D458A9DF for <tls@ietf.org>; Thu, 29 Oct 2009 15:44:09 -0400 (EDT)
Message-ID: <4AE9F0DE.7060903@pobox.com>
Date: Thu, 29 Oct 2009 12:45:34 -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
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 6DECA448-C4C3-11DE-9472-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com
Subject: [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: Thu, 29 Oct 2009 19:43:57 -0000

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