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
>