Re: [Trans] can CT defend against dual CA compromise?

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 26 February 2016 07:38 UTC

Return-Path: <dkg@fifthhorseman.net>
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 556B71ACE0F for <trans@ietfa.amsl.com>; Thu, 25 Feb 2016 23:38:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 rRU-4S4yfNWl for <trans@ietfa.amsl.com>; Thu, 25 Feb 2016 23:38:03 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CA45D1ACE09 for <trans@ietf.org>; Thu, 25 Feb 2016 23:38:02 -0800 (PST)
Received: from fifthhorseman.net (unknown [195.76.232.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 14B4DF999; Fri, 26 Feb 2016 02:37:57 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 9406121138; Fri, 26 Feb 2016 06:02:00 +0100 (CET)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Ben Laurie <benl@google.com>, Tom Ritter <tom@ritter.vg>
In-Reply-To: <CABrd9STH5mnLnfwUroaF7hY3SZeHuWCBYwT1caKma5qF-Epn+w@mail.gmail.com>
References: <87io1i3gqw.fsf@alice.fifthhorseman.net> <CABrd9SQh5B8E8phCvgLdUntKBu=u4p2iUHJ7ZrjqMwz8edwLHA@mail.gmail.com> <56CAF5B2.30207@comodo.com> <CA+cU71m7akWkLFPiTVOShuTBHLVWfA+Byw2vXF-AZtH0Byik5A@mail.gmail.com> <CABrd9ST2fUz+JPxoimvuw_XFeoNEmGNhPpS3w-PC22ZQDez7AA@mail.gmail.com> <87povm27iu.fsf@alice.fifthhorseman.net> <CABrd9SQSMm0Bid_sKwwaK=TX2CD0uNbRJmRCs1CNe-Y0br2=Aw@mail.gmail.com> <CA+cU71mXVv0-61Z9g4H5y+qBR6LOsnu0E+=qWrsozvk5UxQRtw@mail.gmail.com> <CABrd9STH5mnLnfwUroaF7hY3SZeHuWCBYwT1caKma5qF-Epn+w@mail.gmail.com>
User-Agent: Notmuch/0.21+74~gb409435 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Fri, 26 Feb 2016 06:02:00 +0100
Message-ID: <8760xccbef.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/eHt8az2aeRWhIgbam_WCB8JJWow>
Cc: Rob Stradling <rob.stradling@comodo.com>, "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] can CT defend against dual CA compromise?
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 26 Feb 2016 07:38:05 -0000

On Wed 2016-02-24 23:27:34 +0100, Ben Laurie <benl@google.com> wrote:
> https://github.com/agl/crlset-tools (answer: yes, crlsets can blacklist on
> SPKI).

good, i'm glad to hear it.

> Surely no-one has to remember anything ... if a browser-used log logs
> a cert that is for a domain that wasn't expecting that cert to be
> issued, then action needs to be taken.

Sure, but if that action is nothing because "meh, this particular
browser-used log just hasn't rejected certs that chain back to A yet,
and we know that A is bad, so we can just ignore this leaf cert", then
we're in the situation that CT is supposed to prevent.

OTOH, If we expect all browser-used logs to immediately refuse to serve
SCTs that chain to a given root (A) whenever any of A's intermediates
(A_X) is shown to have misissued anything (how do we prove a
misissuance, as opposed to compromise or organizational failure of the
end entity itself again?), then we get to try to coordinate a new set of
multiple parties during an apparent CA compromise (logs this time, in
addition to browser vendors), and log operators themselves need to make
potentially-political decisions about which roots or intermediates to
blacklist and which to continue logging.

More generally, I'm quite concerned that we seem to be adding a second
category of log to the CT ecosystem in an attempt to have an analysis
that doesn't have this dual-CA-compromise issue.

The CT ecosystem is complicated and hard to analyze with only one kind
of log, and now it seems that we have:

 * browser-used logs
 * non-browser-used logs

What are the different requirements of each kind of log?  What kinds of
decisions do the different kinds of log operators need to make?  What
additional data structures do they need to maintain for correct
operation?  How does the ecosystem as a whole depend on them doing their
specific work?  what happens if they fail?  what incentives do people
have to offer one kind of log or another?  Do auditors need to look at
both kinds of logs, or only one?

> Eventually, presumably, everyone will get bored of taking action on
> every cert issued by the compromised CA and deal with the problem in a
> more fundamental way. Such as blacklisting the SPKI.

Who blacklists the SPKI?  All browser vendors?  browser-used logs?
non-browser-used logs?  which SPKI gets blacklisted?  blacklisting the
SPKI of the intermediate cert doesn't work if the root CA is compromised
-- the attacker can just issue a new intermediate.  how many compromised
intermediates does a log need to see before it decides to blacklist the
root CA itself?  Does it need to coordinate such a blacklist with the
browser vendors?  with all of them, or just some of them?

sorry for being all questions and no answers, but this still doesn't
seem resolved to me.

        --dkg