IETF Logo Mail Archive

Re: [TLS] simplistic renego protection

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 26 November 2009 01:08 UTC

Return-Path: <pgut001@wintermute01.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 286253A696E for <tls@core3.amsl.com>; Wed, 25 Nov 2009 17:08:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.459
X-Spam-Level:
X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=-0.860, 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 lKcVQULaXBa8 for <tls@core3.amsl.com>; Wed, 25 Nov 2009 17:08:47 -0800 (PST)
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.36]) by core3.amsl.com (Postfix) with ESMTP id 43E163A6948 for <tls@ietf.org>; Wed, 25 Nov 2009 17:08:47 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 41F629DEC0; Thu, 26 Nov 2009 14:08:42 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TYbgYBjb5V6; Thu, 26 Nov 2009 14:08:42 +1300 (NZDT)
Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 21CBE9DEB7; Thu, 26 Nov 2009 14:08:42 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1NDSqg-00062s-GN; Thu, 26 Nov 2009 14:08:42 +1300
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1NDSqf-0007a4-Vw; Thu, 26 Nov 2009 14:08:42 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: yngve@opera.com
In-Reply-To: <op.u3ydumi7vqd7e2@killashandra.oslo.osa>
Message-Id: <E1NDSqf-0007a4-Vw@wintermute01.cs.auckland.ac.nz>
Sender: pgut001 <pgut001@wintermute01.cs.auckland.ac.nz>
Date: Thu, 26 Nov 2009 14:08:41 +1300
Cc: tls@ietf.org
Subject: Re: [TLS] simplistic renego protection
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, 26 Nov 2009 01:08:48 -0000

"Yngve Nysaeter Pettersen" <yngve@opera.com> writes:

>The reason I was investigating the site was that the EV indication was flip-
>flopping on this site, which turned out to be because one certificate had a
>1024 bit key (which qualifies for EV), the other was using a 1023 bit key
>(which does not qualify for EV).

So the CA issued a certificate that it should never have issued?  And then the
client did more checking than the CA did?  Do other implementations perform
this level of checking of EV conditions as well, or do they just assume that
if the EV flag is set then everything must be OK because the CA says it is?
I'd be interested in feedback from on this one (private is OK if you don't feel
like making it public).

Kinda scary if it's left to the RP to do the CA's work...

Peter.

v2.23.0 | Report a Bug | By Email