Re: [TLS] Server Signature Algorithms

Michael D'Errico <> Sun, 01 November 2009 21:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BA813A6822 for <>; Sun, 1 Nov 2009 13:32:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6IGceaZ3zSt7 for <>; Sun, 1 Nov 2009 13:32:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AEA9F3A67D6 for <>; Sun, 1 Nov 2009 13:32:08 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id D96FA8EF06 for <>; Sun, 1 Nov 2009 16:32:27 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=MotZn9LPl7mu VhQsxfY6BV8GHdk=; b=RbJKFdszYTEe0OaqMS9V5bUguWedVVz7vldasjvZTyG7 +Cp7UDBnG3ZHNX4GvnltRf15Nf1OJBuJvobmjtsfM8GCrAY6wNjBCfXIRVmRY0zL unk37ro6fxnHSfQkGcFv9LE1WLcSXXCF6fYMk0x8k2nbNJPW0ZYDs3+mxrqxgOA=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=KxYdLv R8yFo8X8oVXL4R6Kb8BNZENHntvmBYMqBqNUYJyft7Lv2OzTpQLjnimxlBlUZaj7 Fz3tzdhsXGwTbGJKux3nU0Rx4lMzrJkrukMtRUV0lBFZ9X3WwPntVXc+ZhyGBdvj 9SbBF6ojvAlyHN3fQC8rQQ98VLKWXUe+H3YTI=
Received: from (unknown []) by (Postfix) with ESMTP id D629A8EF05 for <>; Sun, 1 Nov 2009 16:32:27 -0500 (EST)
Received: from administrators-macbook-pro.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 2CC378EF03 for <>; Sun, 1 Nov 2009 16:32:26 -0500 (EST)
Message-ID: <>
Date: Sun, 01 Nov 2009 13:34:08 -0800
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
X-Pobox-Relay-ID: 0D9A25B2-C72E-11DE-9556-A67CBBB5EC2E-38729857!
Content-Transfer-Encoding: quoted-printable
Subject: Re: [TLS] Server Signature Algorithms
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Nov 2009 21:32:11 -0000

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.

In this case, the server can leave the signature algorithms list in
CertificateRequest empty since it knows the client accepted its list
in the server hello extension.  The server MUST NOT send a different
list in CertificateRequest, since the client may have used the
information to start computing the hash for CertificateVerify and
thrown away the previous handshake messages.


Michael Gray wrote:
> "Michael D'Errico" <> 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.
> Currently our toolkit when operating as a client will abort the handshake
> on this condition due to RFC 5246 in saying: “Servers MUST NOT
> send this extension”.
> We could change our code to optionally (e.g. a non strict mode) accept
> receiving the extension from a TLS Server as that would be IMHO relatively
> harmless.  The problem I see would be if we enabled our Server side code to
> optionally send this extension, that would open the door for existing TLS
> Clients to abort the handshake.  We have no idea which Client (vendor) type
> may be involved in a handshake and what revision of the implementation in
> this area they might support i.e., there is no way for the Client to
> indicate that it will tolerate the Server sending the extension.  IMHO It
> is unfortunate version information is not included in each extension.  So
> while I agree that this sounds a good move I would be concerned as to the
> impact on system availability should any Server now be configured to start
> sending this extension.  IMHO I think the horse might have already bolted
> in this case :-(
> Mick