RE: New Liaison Statement, "Liaison to IETF on the resolution of DR320"

"Santosh Chokhani" <chokhani@orionsec.com> Thu, 25 October 2007 13:53 UTC

Return-path: <owner-ietf-pkix@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il39k-0004QX-HX for pkix-archive@lists.ietf.org; Thu, 25 Oct 2007 09:53:52 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il39Z-0004Aj-7T for pkix-archive@lists.ietf.org; Thu, 25 Oct 2007 09:53:42 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9PCoQQx000686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2007 05:50:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9PCoQoU000685; Thu, 25 Oct 2007 05:50:26 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net ([66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9PCoPVb000676 for <ietf-pkix@imc.org>; Thu, 25 Oct 2007 05:50:26 -0700 (MST) (envelope-from chokhani@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
Date: Thu, 25 Oct 2007 05:50:10 -0700
Message-ID: <82D5657AE1F54347A734BDD33637C87909945C47@EXVS01.ex.dslextreme.net>
In-Reply-To: <20071025084358.GD4999@mars.cry.pto>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: New Liaison Statement, "Liaison to IETF on the resolution of DR320"
thread-index: AcgW7nGtamqKqlMNTXKUbsczXflWXQAFwyxA
References: <OF49CACE0F.A054F73F-ONC125737C.0041B2BD@frcl.bull.fr> <82D5657AE1F54347A734BDD33637C8790987D3BC@EXVS01.ex.dslextreme.net> <20071022143330.GQ4999@mars.cry.pto> <82D5657AE1F54347A734BDD33637C8790987D7E4@EXVS01.ex.dslextreme.net> <20071025084358.GD4999@mars.cry.pto>
From: Santosh Chokhani <chokhani@orionsec.com>
To: Julien Stern <julien.stern@cryptolog.com>, ietf-pkix@imc.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l9PCoQVb000680
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e

Julien,

It is very simple.  Point to me to the specific post or e-mail me (not
the entire mail list) your protection approach.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]
On Behalf Of Julien Stern
Sent: Thursday, October 25, 2007 4:44 AM
To: ietf-pkix@imc.org
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution
of DR320"


Santosh,

I think you are being a bit unfair, as I did explain on the list
as clearly as I could the attack and the protection (early Nov 2004).

Anyway, I do not feel like boring other readers to death by starting
the whole discussion once again.

Maybe we can sit down at a table and chat if we happen to meet at a
conference someday :)

Regards,

--
Julien

On Mon, Oct 22, 2007 at 10:41:10AM -0700, Santosh Chokhani wrote:
> Julien,
> 
> What I recall is that your attack was a CA trusted to issue CA
> certificates by the relying party going rogue.  X.509 does not protect
> against that.
> 
> You also mentioned that you had protection against it, you were
> unwilling to share it, and you said that you will share it after you
> publish your work.
> 
> I have yet to see your proposal.
> 
> As a matter of fact on PKIX or X.500 forum within last year again I
> asked you to share your proposal and you never replied.
> 
> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Julien Stern
> Sent: Monday, October 22, 2007 10:34 AM
> To: ietf-pkix@imc.org
> Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution
> of DR320"
> 
> 
> On Mon, Oct 22, 2007 at 06:18:22AM -0700, Santosh Chokhani wrote:
> > 
> > We have been down this route before.
> 
> Oooooh Yes. Lots of fun and (gentle) arguments...
> 
> > See my presentation to PKIX in Fall 2004 IETF meeting in Washington
> DC.
> > 
> > My understanding from 2004 presentation was that Russ Housley
proposed
> instead of ensuring certificate certification path and CRL
certification
> path matching, we make sure that we ensure that the paths begin at the
> same trust anchor.  It was felt by the group (not I) that coupled with
> name constraints in cross certified environment is sufficient to
> mitigate the risk to an acceptably low level.  Of course, my argument
> always has been that using the certificate certification path to
> constrain the CRL certification path provides you both with security
and
> efficiency, something you do not always get.  The primary reason to
not
> adopt my suggestion is that it requires change to client software.
> 
> I did not feel either that trust anchor matching was sufficient
enough.
> 
> As you may remember, I also felt that your proposed solution, while
> improving the situation, did not close every possible attacks, and I
> proposed an alternative that was (in my humble opinion) even more
secure
> but with even more changes on the client software.
> 
> Anyway, my current take on the subject would be roughly the following.
> RFC3280bis could include something in the line of:
> 
> "The uniqueness of DN of all entities in all the Trust Anchors
> hierarchies SHOULD be enforced. If the uniqueness cannot be guaranteed
> in some circonstances, client software MAY implement additional checks
> in order to lower the risk of outputing an incorrect revocation value
> during
> path validation. [We could give example of additional checks here:
> checking the trust anchor matching, check the full path matching,
> checking the AuthorityKeyIdentifier hash matching, etc]. Client
> implementors should however be aware that these additional checks may
> hinder interoperability in the general case."
> 
> --
> Julien
> 
>