Re: [Trans] can CT defend against dual CA compromise?
Ben Laurie <benl@google.com> Tue, 23 February 2016 11:06 UTC
Return-Path: <benl@google.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 52FD21AC3B0 for <trans@ietfa.amsl.com>; Tue, 23 Feb 2016 03:06:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level:
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
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 5ct-YAg_d2cE for <trans@ietfa.amsl.com>; Tue, 23 Feb 2016 03:06:26 -0800 (PST)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3CB1A9074 for <trans@ietf.org>; Tue, 23 Feb 2016 03:06:26 -0800 (PST)
Received: by mail-ig0-x22d.google.com with SMTP id y8so108516427igp.0 for <trans@ietf.org>; Tue, 23 Feb 2016 03:06:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=AWGqw16v5ZJxcm4uaXNlME21bi3I4Y9ZkhU8GhKyb8Q=; b=JA/b5lrFO3Wux3tzQyNiXT/LbVmudESnxuXEHP79pjwuEXaIabtmliBvOBOA9KDwBf YLq4izAyLw/8HnpN/KYqwnvN8PZh6e0alkZ2/MrBigYwhnAUhfPo6XcxjUobBeH0NKHR rr2QplBBDAI0G8XfBiIG7+aOqzJgEGzNnKVQl65MIy/zSXXfaj98kKpKQjrE9Okh5Zee Xtzmde0UVTMjNqcU6Ofz1xI8rAmsCyYje7ifLNI21ipNyE2TCqHdNeqd6FcHn76q/K6e TeIRCnWLuTuOyPNkuXmFx3xROsCXq7NgicS9mStRpQPTukPvVIp7v/ZlzsnvKLifRMK7 wlMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=AWGqw16v5ZJxcm4uaXNlME21bi3I4Y9ZkhU8GhKyb8Q=; b=Rz80mITcf4db26cohls9h3nFEblNo9ZZRd0+7v9ogEA3VNxEqyiyz4xFd9L/hLNRom 0vs468fs8CbDqJeDFf0IcsfhREqwf1Wmtr1gu7rzF9xMLD7eJrjSqQQyq5Vb+GWkRuQV cfzJujvXgHgJONIctH+QwLGW4PFEpQzqo6u1hcjq5h85IqdoMDUBTDtK6ts0R6c8IWNx LPhsXatDj2V4bByzvgsFSIDCNpZ+QjoVzag625tBCAHAQ0w7VXxyuLE8j+2dSjd6YMsZ 5qYHtSYCGcmrV4uZ3r9xNGV2b54exnouUS+QaOQxUkId4YROufe6/qjAa1MK6H2R84of e//g==
X-Gm-Message-State: AG10YOSVGXaHMRsT6f+5hTaogh/wZHzefef7B6v7c7j0ZpudJ0DKBKHW5bjucXBQpp1YNjfCPbsmF96CS++iGaBQ
MIME-Version: 1.0
X-Received: by 10.50.33.80 with SMTP id p16mr15737528igi.23.1456225585299; Tue, 23 Feb 2016 03:06:25 -0800 (PST)
Received: by 10.64.26.98 with HTTP; Tue, 23 Feb 2016 03:06:25 -0800 (PST)
In-Reply-To: <CA+cU71m7akWkLFPiTVOShuTBHLVWfA+Byw2vXF-AZtH0Byik5A@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>
Date: Tue, 23 Feb 2016 11:06:25 +0000
Message-ID: <CABrd9ST2fUz+JPxoimvuw_XFeoNEmGNhPpS3w-PC22ZQDez7AA@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Tom Ritter <tom@ritter.vg>
Content-Type: multipart/alternative; boundary="089e01538d8cb9fd3d052c6df03f"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/BmJyLB1ArB1zwMPkZSh4iozGXb4>
Cc: Rob Stradling <rob.stradling@comodo.com>, "trans@ietf.org" <trans@ietf.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
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: Tue, 23 Feb 2016 11:06:28 -0000
On 23 February 2016 at 06:03, Tom Ritter <tom@ritter.vg> wrote: > I'm interleving Ben's and Rob's responses here: > > >> Note that in this scenario, it's unlikely that space-constrained > >> blacklist-style client updates (e.g. CRLset) will include every leaf > >> certificate that chains to A after A is known-compromised. So TLS > >> clients won't necessarily be warned off of C directly. > > > > [Ben] > > It seems to me there are multiple solutions here. The easiest is to not > > blacklist A_X, but instead to blacklists A_X's subject, which will also > > blacklist B_X. > > Perhaps. > > > [Rob] > > I think that blacklisting the shared issuer public key would be better > than > > blacklisting the shared issuer name. > > At first glance, I agree - but there is that annoying trick where you > can generate multiple (or at least two) public keys that all certify > the same signature. So I'm not sure this would actually work. > Hmm. That would be e and e + phi(n), I guess? > > > [Rob] > > AIUI, MS CryptoAPI prefers to build certificate chains using the > > Authority/Subject Key Identifiers, and it only cares about whether or not > > the Issuer/Subject Names match if AKI/SKI are absent. > > AKI would _not_ match on these trick public keys, but presumably the > algorithm would fall back to the Issuer name...? > > > [Ben] > > To be more selective, blacklist the individual certs that were mis-issued > > (we have a complete list, of course, in the logs) and stop accepting new > > certs signed by X. > > The "stop accepting new certs" thing might trip us up. We would like a > mechanism to track the misissued certs of a compromised CA. Trust > Stores have age. We don't distrust X all at once, and it'd be good to > know what X is doing so we can understand our risk on the older > devices. > Fair point. At least two ways of doing this: a) Run a log that is not trusted for HTTPS connections. b) Continue to accept certs from X, but don't allow SCTs after the last good timestamp for X. > > > >> * logs could refuse to log any certs that chain back to a known-failed > >> CA (or through a known-bad intermediate CA). This would constrain a > >> dual-compromise attacker from minting new certs after the first CA is > >> known to be compromised. This seems like a useful mitigation, but > >> it's also complictated and delicate. What does "known-failed" mean? > >> What if there is a dispute over the validity of a cert, with one > >> party claiming that it was misissued, and the CA claiming its > >> legitimacy? What if some browser vendors have dropped the CA, and > >> others have not? This puts the logs in a position of being some kind > >> of arbiter of the root store, with very subtle knock-on effects to > >> security of the whole ecosystem if they decide to not drop a CA. > > > > [Ben] > > Not all that subtle, surely, and completely visible so we can see its > going > > on... > > As I said above - up until here the CT logs have been a good viewpoint > on the CA ecosyetem. Aggressively removing CAs seems dangerous from a > "track the ecosystem and ensure accountability" perspective. > > > > [Rob] > > - say that TLS clients SHOULD fetch and verify inclusion proofs for all > > intermediate certs that they rely on. > > I'm nervous about this. > > -tom >
- [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