IETF Logo Mail Archive

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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sat, 05 March 2011 06:38 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 01FD03A689F for <tls@core3.amsl.com>; Fri, 4 Mar 2011 22:38:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.542
X-Spam-Level:
X-Spam-Status: No, score=-103.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 ooN5u9paPBOM for <tls@core3.amsl.com>; Fri, 4 Mar 2011 22:38:27 -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 063263A684D for <tls@ietf.org>; Fri, 4 Mar 2011 22:38:24 -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=1299307177; x=1330843177; 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<201103042127.p24LRi x4011668@fs4113.wdf.sap.corp>|Message-Id:=20<E1Pvl9H-0006 Ng-Oe@login01.fos.auckland.ac.nz>|Date:=20Sat,=2005=20Mar =202011=2019:39:31=20+1300; bh=I+tCNJ4zjJgVKk6wDcs8dB6RI084EB68GyjZfCbzzXM=; b=EsC68EA31NWjC00vAJCnasAnWytmndX2JMqr4Uq//bwGkIfrQ/rjdbj4 yKJUKKDiCuQAaa8tSamFygGRXSkeuOaEBeOWa2JqU90qnyc1icGTpRl5+ AWtSy6oCTyr6/0eOb4DJ7WkuOnpxUDf27ZzCaK0zaR+pzQD4WryN2FvRm k=;
X-IronPort-AV: E=Sophos;i="4.62,268,1296990000"; d="scan'208";a="49273925"
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; 05 Mar 2011 19:39:32 +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 1Pvl9H-0007dx-Ik; Sat, 05 Mar 2011 19:39:31 +1300
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1Pvl9H-0006Ng-Oe; Sat, 05 Mar 2011 19:39:31 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: mrex@sap.com
In-Reply-To: <201103042127.p24LRix4011668@fs4113.wdf.sap.corp>
Message-Id: <E1Pvl9H-0006Ng-Oe@login01.fos.auckland.ac.nz>
Date: Sat, 05 Mar 2011 19:39:31 +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, 05 Mar 2011 06:38:29 -0000

Martin Rex <mrex@sap.com> writes:

>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 is not just shooting yourself in the foot, that is shooting "the whole
>nine yards" (the entire ammunition belt) in your foot.

Just out of interest, how are other implemeters dealing with this?  I looked
at that requirement in the spec, decided it was totally crazy, and ignored it.
So far I haven't found any other TLS 1.2 implementation (of the very few that
are around) that has any problems with this, so my guess is everyone else is
ignoring it as well.

(There are a couple of other things in there that are completely nuts as well,
if we could document the general consensus on what to ignore it might help
other implementors who, God help us, decide to try and follow the spec).

Peter.

v2.23.0 | Report a Bug | By Email