[TLS] Will CAs decide server signing algorithms in TLS 1.2?

Simon Josefsson <simon@josefsson.org> Wed, 25 April 2007 11:58 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgg8L-0003PG-Ih; Wed, 25 Apr 2007 07:58:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgg8K-0003PB-9v for tls@ietf.org; Wed, 25 Apr 2007 07:58:04 -0400
Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgg8J-0003Hl-Si for tls@ietf.org; Wed, 25 Apr 2007 07:58:04 -0400
Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l3PBvupr019691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Wed, 25 Apr 2007 13:58:00 +0200
X-Hashcash: 1:22:070425:tls@ietf.org::/WnwgM1YAYa1tsj0:vj6O
From: Simon Josefsson <simon@josefsson.org>
To: tls@ietf.org
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 25 Apr 2007 13:57:56 +0200
Message-ID: <87slao8y4b.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.98 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Status: No, score=-0.8 required=4.0 tests=AWL,BAYES_50, FORGED_RCVD_HELO autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc:
Subject: [TLS] Will CAs decide server signing algorithms in TLS 1.2?
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

The Signature structure has changed, and the current text in section
7.4.3 says:

   If the SignatureAlgorithm being used to sign the ServerKeyExchange
   message is DSA, the hash function used MUST be SHA-1. If the
   SignatureAlgorithm it must be the same hash function used in the
                     ^^^^^^^^^^^^^^^^
   signature of the server's certificate (found in the Certificate)
   message. This algorithm is denoted Hash below. Hash.length is the
   length of the output of that algorithm.

I can't parse the second sentence here.  What is the intention here?

I'm assuming that the intention is to say that the SignatureAlgorithm
must be the same as the signing algorithm in the server certificate.

It seems weird that the CA who signs the server certificate will
implicitly decide which signature algorithm is used inside TLS between
all servers and clients.

As far as I can tell, it is not possible for a server or client to
negotiate the use of another hash algorithm (for the purpose of key
exchange and certificate verification) than what the CA used to sign the
certificates with, given the above text.  That seems sub-optimal.

Two examples of real-world problems:

1) A server and/or client have RSA-SHA1 certificates.  They wish to use
   RSA-SHA256 in the ServerKeyExchange and CertificateVerify messages,
   but they can't negotiate that.

2) A server and/or client have RSA-MD5 certificates (there are many of
   these out there).  They wish to use RSA-SHA1 or RSA-SHA256 in the
   ServerKeyExchange and CertificateVerify messages, but they can't
   negotiate that.

An argument that using RSA-SHA256 (or RSA-SHA1), when the server
certificate is signed using RSA-SHA1 (or RSA-MD5), do not increase the
security is flawed.  It is possible for clients to check a server's
certificate fingerprint out of band, and essentially thus trust the
server certificate directly.  In this situation, the signature algorithm
used in the server certificate is never used for verification, and thus
does not influence the overall security.  This is what some
implementations use to achieve "leap-of-faith" security against
untrusted servers.  With the current text, the overall security is
restricted by what the server and client CA's have chosen.

I predict that RSA-SHA256 certificates will cost ten times as much as
RSA-SHA1 certificates if this text stays...

/Simon

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls