IETF Logo Mail Archive

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

Michael D'Errico <mike-list@pobox.com> Sat, 05 March 2011 07:36 UTC

Return-Path: <mike-list@pobox.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 2439B3A689E for <tls@core3.amsl.com>; Fri, 4 Mar 2011 23:36:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599]
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 eI9Lfand6nxd for <tls@core3.amsl.com>; Fri, 4 Mar 2011 23:36:09 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id B16C23A6800 for <tls@ietf.org>; Fri, 4 Mar 2011 23:36:08 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C7A4D2719; Sat, 5 Mar 2011 02:38:41 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=+tB3/bIDZn7E 1wjSsFknXQyf7zM=; b=dzsZah4Re3JclrVJPSAvRZVCT4NMI6sfnr4OeWXtn430 euM08YVSRYa70Z67YahVtCK8qZDXxZhNtMF+tNloiy6GEDIfPqvSKNWbrkjOBNEg XLp4bNZ+aeDAZyrsu+CDMTfq8d1VdOkul1Mt+1/DsjYJ8ithwaTHpGSyd22npTI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=YKvKJ2 So1VJCKBfC5PdvzDUCTLQlkHwk9elCVMe3iwFSYNv3MEKC7kLutrQTY9AnNuS7nF Juu2JyQNtO9pkfdb16k2rT4F0J3VV9R1biK/lv2a9JPaLVqi6sx0DtK290Y/BNcl yWSPmkive8a3GNDgaYGTfy7DSD7dsMScKjPQY=
Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B30712718; Sat, 5 Mar 2011 02:38:40 -0500 (EST)
Received: from iMac.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 2E5532717; Sat, 5 Mar 2011 02:38:38 -0500 (EST)
Message-ID: <4D71E82A.2010702@pobox.com>
Date: Fri, 04 Mar 2011 23:37:14 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
References: <E1Pvl9H-0006Ng-Oe@login01.fos.auckland.ac.nz>
In-Reply-To: <E1Pvl9H-0006Ng-Oe@login01.fos.auckland.ac.nz>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 971A593A-46FB-11E0-A3C6-AF401E47CF6F-38729857!a-pb-sasl-sd.pobox.com
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 07:36:11 -0000

Peter Gutmann wrote:
> 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.

My TLS code doesn't validate the server's certificate chain.  Instead it
passes all of the information to a callback function registered by the
application; the return code determines whether to continue the handshake
or not.

See, TLS 1.2 isn't so hard to implement after all.  :-)

> (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).

Can you please list the other things you found to be completely nuts?

Thanks,

Mike

v2.23.0 | Report a Bug | By Email