Re: [Trans] path validation

Stephen Kent <kent@bbn.com> Thu, 02 October 2014 16:13 UTC

Return-Path: <kent@bbn.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BB31A87CD for <trans@ietfa.amsl.com>; Thu, 2 Oct 2014 09:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level:
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3U3uYkF0LmL for <trans@ietfa.amsl.com>; Thu, 2 Oct 2014 09:13:50 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1581A8789 for <trans@ietf.org>; Thu, 2 Oct 2014 09:13:50 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:38307 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XZj11-000Eqs-VS; Thu, 02 Oct 2014 12:14:04 -0400
Message-ID: <542D79BB.1030900@bbn.com>
Date: Thu, 02 Oct 2014 12:13:47 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: David Leon Gil <coruus@gmail.com>
References: <54296FB2.1060109@bbn.com> <4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <CAA7UWsWr2p7t2uTrhiF9meU8htT=aWQT7qiBV6Xxg2E-GAwUBQ@mail.gmail.com> <542C0FCB.7010906@bbn.com> <CAA7UWsW8qM8jdOOjdEznmyW6iEcnQ58izuMCbZbRtHWSQmBp5Q@mail.gmail.com>
In-Reply-To: <CAA7UWsW8qM8jdOOjdEznmyW6iEcnQ58izuMCbZbRtHWSQmBp5Q@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ul73Iw-XaziRaLtAElkgnRcitTY
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] path validation
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Oct 2014 16:13:58 -0000

David,

> On Wed, Oct 1, 2014 at 10:29 AM, Stephen Kent<kent@bbn.com>  wrote:
>> I disagree. Once Ben said that he meant mis-issuance to be interpreted in a
>> much broader context,
>> and cited EV cert requirements as an example, I pursued documenting what
>> that would mean. If
>> the WG wants to say that mis-issuance is more than issuing a cert to the
>> wrong Subject, then
>> we need to say just what it is, not hand wave.
> You are missing the point of certificate transparency.
I may, since the definition of the goals seem to change over time.
> We have no idea all the forms that misissuance -- particularly
> malicious misissuance -- might take. If it were trivial to detect
> "misissuance", browsers would validate certs for "misissuance" and the
> problem would be solved.
History suggests otherwise. We have seen many examples of browsers not
performing cert path validation correctly, e.g., not paying attention to
the basicConstrants extension (with serious security consequences), etc.
So browsers are not a reliable way to deal with many cert-related 
security concerns.

More to the point, CT is a set of external mechanisms designed to detect
mis-issuance that might not be visible to an individual TLS client. So your
argument that if it were trivial to detect, browsers would do it, is way
off the mark.
> The point of having a log that includes everything signed with a CA's
> key is that analysis of issued certificates can be conducted post-hoc.
Well, to be accurate, CRLs are not logged, as per the current proposal,
so it's not "everything signed with a CA's key." But, irrespective of
that detail, I am not suggesting that we alter the post-hoc analysis;
I was suggesting that there might be benefits to checking at the time
of issuance, principally in the case of pre-certs.
> Proposals to limit the scope of what logs can log kneecap CT. They
> should not be considered.
What CT does should or should not be ought to be justified based on an
analysis of attacks and what CT does to address them, not on blanket 
statements
that mis-issuance cannot be defined.

Steve