IETF Logo Mail Archive

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

Eric Rescorla <ekr@rtfm.com> Thu, 17 February 2011 13:39 UTC

Return-Path: <ekr@rtfm.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 E644F3A6E0C for <tls@core3.amsl.com>; Thu, 17 Feb 2011 05:39:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.947
X-Spam-Level:
X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 8Wo7qJD7LwNf for <tls@core3.amsl.com>; Thu, 17 Feb 2011 05:39:28 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1DCFD3A6E04 for <tls@ietf.org>; Thu, 17 Feb 2011 05:39:28 -0800 (PST)
Received: by iwc10 with SMTP id 10so2669587iwc.31 for <tls@ietf.org>; Thu, 17 Feb 2011 05:39:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.228.5 with SMTP id jc5mr2751393icb.228.1297949998882; Thu, 17 Feb 2011 05:39:58 -0800 (PST)
Received: by 10.42.178.193 with HTTP; Thu, 17 Feb 2011 05:39:58 -0800 (PST)
In-Reply-To: <AANLkTikpH43-prtxtzPgrarjOAZUmps6=17bpCa93GE6@mail.gmail.com>
References: <201102162335.p1GNZ0Yd009478@fs4113.wdf.sap.corp> <4D5C65D2.4060502@pobox.com> <4D5CE08C.5060402@gnutls.org> <AANLkTimsFTBw=WtOopKfQkPnKJJH83kaHYuN89GBLEPC@mail.gmail.com> <AANLkTi=A61NKuyY6fZ2kaMfYOL1R4pHdvHUeVtWMhXpR@mail.gmail.com> <AANLkTikNYQ2h=fLnwscf-d=CfQoFoH0bZ9_MAnLNX86J@mail.gmail.com> <AANLkTikpH43-prtxtzPgrarjOAZUmps6=17bpCa93GE6@mail.gmail.com>
Date: Thu, 17 Feb 2011 15:39:58 +0200
Message-ID: <AANLkTimjBqGEp=yAJYFHN6mSx794udvTjLs-7eEgo410@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: tls@ietf.org
Subject: Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client cert and
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, 17 Feb 2011 13:39:29 -0000

On Thu, Feb 17, 2011 at 1:17 PM, Nikos Mavrogiannopoulos
<nmav@gnutls.org> wrote:
> On Thu, Feb 17, 2011 at 11:54 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>>> Note that you're talking about the hashes required for the finished
>>> messages and you're correct on this note. However there is also the
>>> hash required for the CertificateVerify message. If the server requests
>>> a client certificate then it has to store all messages up to (but not
>>> including) the CertificateVerify message.
>>> That is because he cannot possibly know which signature algorithm
>>> hash the client will use.
>> Agreed. I can't recall if we discussed this when this feature was being designed
>> for 5246 but ISTM that the only way to have this work that didn't have
>> this property would be for the client to offer all his certificates
>> up-front and the
>> server to select one, since it's possible that each cert comes with a specific
>> hash algorithm tied to it.
>
> To which PKIX certificate field are you referring to?

I'm not. I'm talking about environments where (for instance) some of
your keys are in
hardware and so, can only be used to with a specific hash algorithm.
It's not incredibly
common, but I have seen it.

-Ekr

v2.23.0 | Report a Bug | By Email