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
- [Trans] can CT defend against dual CA compromise? Daniel Kahn Gillmor
- Re: [Trans] can CT defend against dual CA comprom… Ben Laurie
- Re: [Trans] can CT defend against dual CA comprom… Rob Stradling
- Re: [Trans] can CT defend against dual CA comprom… Tom Ritter
- Re: [Trans] can CT defend against dual CA comprom… Rob Stradling
- Re: [Trans] can CT defend against dual CA comprom… Ben Laurie
- Re: [Trans] can CT defend against dual CA comprom… Daniel Kahn Gillmor
- Re: [Trans] can CT defend against dual CA comprom… Rob Stradling
- Re: [Trans] can CT defend against dual CA comprom… Ben Laurie
- Re: [Trans] can CT defend against dual CA comprom… Tom Ritter
- Re: [Trans] can CT defend against dual CA comprom… Tom Ritter
- Re: [Trans] can CT defend against dual CA comprom… Ben Laurie
- Re: [Trans] can CT defend against dual CA comprom… Daniel Kahn Gillmor