IETF Logo Mail Archive

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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Thu, 17 February 2011 11:17 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 917463A6C8D for <tls@core3.amsl.com>; Thu, 17 Feb 2011 03:17:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 VVXaJJIVwQ-b for <tls@core3.amsl.com>; Thu, 17 Feb 2011 03:17:24 -0800 (PST)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id B92BE3A6C87 for <tls@ietf.org>; Thu, 17 Feb 2011 03:17:24 -0800 (PST)
Received: by qyj19 with SMTP id 19so2384399qyj.10 for <tls@ietf.org>; Thu, 17 Feb 2011 03:17:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7QcWzC80c/PjjQxeXkYR59LeN6bMF5mjrNyKg3fKy8A=; b=RnNE3xihU4V5WIcOZUmpYFcMHR/r161+85bHM0bawGf9YqDtITNRr/BgvPRXHEdyIN U58WggpY7AM7g9L9Pk4o/NPAF0cXCaWY0tWoj8GysCNMfWIF6pPqDbPBTndIwJmA0SS9 b2iFwm60gCS5hVKGCcneHTl7Fxa9CLR0NjCho=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=QM2YipOloj83PidyX5zl9QYcS85I8LwdQE3pQW6bjVBMG6qtUO5cPlu1M7u3KA4Xit XHpD1fH8jFa5mx371scezNaoPagUxfKx5GCJT4b6tqpPYaRBxkpDGmMoM11DSUvqGbVF v0qpdnDEwcXpnaRn4c5Udy90u1rfjArYIk3UQ=
MIME-Version: 1.0
Received: by 10.229.220.83 with SMTP id hx19mr2158850qcb.52.1297941474248; Thu, 17 Feb 2011 03:17:54 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.229.232.18 with HTTP; Thu, 17 Feb 2011 03:17:54 -0800 (PST)
In-Reply-To: <AANLkTikNYQ2h=fLnwscf-d=CfQoFoH0bZ9_MAnLNX86J@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>
Date: Thu, 17 Feb 2011 12:17:54 +0100
X-Google-Sender-Auth: vgUcPpW_t9QvNdMfag1FdDdYdlw
Message-ID: <AANLkTikpH43-prtxtzPgrarjOAZUmps6=17bpCa93GE6@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
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 11:17:25 -0000

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?

regards,
Nikos

v2.23.0 | Report a Bug | By Email