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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Thu, 17 February 2011 14:45 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 D062F3A6F07 for <tls@core3.amsl.com>; Thu, 17 Feb 2011 06:45: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 Rhl4UvraNspx for <tls@core3.amsl.com>; Thu, 17 Feb 2011 06:45:25 -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 DEFBB3A6EEF for <tls@ietf.org>; Thu, 17 Feb 2011 06:45:24 -0800 (PST)
Received: by qyj19 with SMTP id 19so2561008qyj.10 for <tls@ietf.org>; Thu, 17 Feb 2011 06:45: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 :content-transfer-encoding; bh=5MFZ69Nmx9vSVRlx4aCdFkW5ewKoN+BAaOTPVPFgRCk=; b=lkZjzoo9zk+0gDrqDQDKk/YNOXioe78b6djEvZI5d02Gqese2Ip/aaO6vd+w+sb3aA hlqa+4XVlV3sBldp7jWI+S6ux1FHF1f2bjU5bTc9Iqp1ZFCKFZwlGKK4mdAQUPt0YOpz z9gndDxGW05ImRNNQ1v5rrVZ/kOb97mKwHxO8=
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 :content-transfer-encoding; b=YVgfmF5MDQcl/CAe58gbE6DdvSKrLrDd46hx2fvuPQAjtSoJESiW7cLyq0aP8WDEav mpiAXZ5a4LM76xv2dvWYBpzXU0IeiUaJXV7nG0AdGYKUtm6ijm58QK9LMjDnIjWlm2lF zeIzS8pR3xOuRoazLoiH8h9OjqrzFJf+J535U=
MIME-Version: 1.0
Received: by 10.229.218.197 with SMTP id hr5mr2446715qcb.14.1297953955471; Thu, 17 Feb 2011 06:45:55 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.229.232.18 with HTTP; Thu, 17 Feb 2011 06:45:55 -0800 (PST)
In-Reply-To: <op.vq1ss6hkqrq7tp@acorna.oslo.osa>
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> <op.vq1ss6hkqrq7tp@acorna.oslo.osa>
Date: Thu, 17 Feb 2011 15:45:55 +0100
X-Google-Sender-Auth: XLgUsgVC5M26hdvd-Ae8ykHgj8Y
Message-ID: <AANLkTinVUWmtFLpwV1nr0HFMRi9-3ef239k6jNSQFg9H@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 14:45:25 -0000

On Thu, Feb 17, 2011 at 1:54 PM, Yngve N. Pettersen (Developer Opera
Software ASA) <yngve@opera.com> wrote:
>> 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.
> How about removing the need to calculated the verify message based on a
> specific hash of the handshake message?
> Currently the verify message is defined as
>      struct {
>           digitally-signed struct {
>               opaque handshake_messages[handshake_messages_length];
>           }
>      } CertificateVerify;
> How about changing that to this?
>      struct {
>           digitally-signed struct {
>                PRF(master_secret, verify_label, Hash(handshake_messages))
>                          [0..f(Cert_Hash)-1];
>           }
>      } CertificateVerify;

This is a nice idea for 1.3. (I'd replace Cert_Hash with selected_hash though).

regards,
Nikos