IETF Logo Mail Archive

Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client

Geoffrey Keating <geoffk@geoffk.org> Fri, 04 March 2011 22:05 UTC

Return-Path: <geoffk@geoffk.org>
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 E9CE128C0E7 for <tls@core3.amsl.com>; Fri, 4 Mar 2011 14:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level:
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 7dq2UUEXt5so for <tls@core3.amsl.com>; Fri, 4 Mar 2011 14:05:16 -0800 (PST)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by core3.amsl.com (Postfix) with ESMTP id 0A78028C0EB for <tls@ietf.org>; Fri, 4 Mar 2011 14:05:16 -0800 (PST)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 7657533D199; Fri, 4 Mar 2011 22:06:24 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: mrex@sap.com
References: <4D714887.6060003@pobox.com> <201103042127.p24LRix4011668@fs4113.wdf.sap.corp>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Fri, 04 Mar 2011 14:06:24 -0800
In-Reply-To: <201103042127.p24LRix4011668@fs4113.wdf.sap.corp>
Message-ID: <m2r5amh76n.fsf@localhost.localdomain>
Lines: 24
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: tls@ietf.org
Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client
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, 04 Mar 2011 22:05:17 -0000

Martin Rex <mrex@sap.com> writes:

> Michael D'Errico wrote:
> > 
> > Matt DeMoss wrote:
> > > I'd encourage consideration of client certificates also. If the client
> > > has certificate chains for SHA1 and SHA2 or for SHA2 and SHA3, it
> > > needs a way to choose which chain to send during periods of transition
> > > where some servers will reject SHA2 and others will reject SHA3.
> > 
> > Isn't this already in TLS 1.2?  When the server requests a client
> > certificate, the CertificateRequest includes a list of acceptable
> > signature algorithms.  The client can then check each of its
> > certificate chains to find the best one the server can handle.
> 
> It is *MUCH* worse than that.
> 
> TLSv1.2 goes as far as _requiring_ that if the signature_algorithm
> extension is sent, that the receiver MUST ensure that all certificates
> in the chain are from the signature_algorithm set.

That's in the server's chain, though, not the client's.  For the
client, the possible certificate algorithms and types are listed in the
CertificateRequest, not in an extension, and the list is not optional.

v2.23.0 | Report a Bug | By Email