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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sat, 19 February 2011 07:23 UTC

Return-Path: <pgut001@login01.cs.auckland.ac.nz>
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 58DD53A6DA5 for <tls@core3.amsl.com>; Fri, 18 Feb 2011 23:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 g1oj5UBd0Ry0 for <tls@core3.amsl.com>; Fri, 18 Feb 2011 23:23:52 -0800 (PST)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id B5FD03A6D24 for <tls@ietf.org>; Fri, 18 Feb 2011 23:23:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298100267; x=1329636267; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20mrex@sap.com|Subject:=20Re:=20[TLS]=20TLS=20v1.2 =20performance=20(was=20Re:=20TLSv1.2=20with=20DSA=20clie nt|Cc:=20tls@ietf.org|In-Reply-To:=20<201102190352.p1J3qL 8N005353@fs4113.wdf.sap.corp>|Message-Id:=20<E1PqhB2-0001 rq-6o@login01.fos.auckland.ac.nz>|Date:=20Sat,=2019=20Feb =202011=2020:24:24=20+1300; bh=udwF49zc0fdbZeWaqF9uIveWbnI9J/jy6ec0KbNsfPA=; b=BPmR+cTcf31jE9co0bky1ZNI/jyNNlqrsDKspdx75+yKWxQVhUh6kxoq uEvWv7bXwYqOJSVNgGQVAPZLv1MTN9WDR9uu/VX4LAQ/uWawyOf9sQXNP lh+FddlEkExhN34dLwutFEM18/QiNr7pRNiczuB8mqW+eMpFAJPkOS4gP 0=;
X-IronPort-AV: E=Sophos;i="4.62,191,1296990000"; d="scan'208";a="46902670"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Feb 2011 20:24:24 +1300
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1PqhB2-0005nE-Gx; Sat, 19 Feb 2011 20:24:24 +1300
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1PqhB2-0001rq-6o; Sat, 19 Feb 2011 20:24:24 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: mrex@sap.com
In-Reply-To: <201102190352.p1J3qL8N005353@fs4113.wdf.sap.corp>
Message-Id: <E1PqhB2-0001rq-6o@login01.fos.auckland.ac.nz>
Date: Sat, 19 Feb 2011 20:24:24 +1300
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: Sat, 19 Feb 2011 07:23:54 -0000

Martin Rex <mrex@sap.com> writes:

>What does your private extension look like?

Just an I-am-here for my own code, which imples only SHA-256 will be used and
there's no need to do any other type of hashing (it also implies some other
things that allow shortcuts in processing).

>I also think it should be fairly easy to fix with a simple TLS extension that
>negotiates _only_ the hash that is going to be used for the digitalSignature
>struct in ServerKeyExchange or CertificateVerify.

Yup, that would be the more general way of doing it, the client provides a set
of choices and the server picks the one that it wants, so the client has to
cache at most one message and the server none.

>Such an extension could be used with TLSv1.0 and TLSv1.1 as well and would
>make the FIPS 186-3 DSA >1024 bit signatures work as well as ECDSA signatures
>(rfc-4492) with SHA-256.

Yup, it would certainly make the handshake less painful.

Peter.