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

Tom Ritter <tom@ritter.vg> Wed, 24 February 2016 14:17 UTC

Return-Path: <tom@ritter.vg>
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 925221AD350 for <trans@ietfa.amsl.com>; Wed, 24 Feb 2016 06:17:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 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, 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 I9iz0zt_NpuW for <trans@ietfa.amsl.com>; Wed, 24 Feb 2016 06:17:06 -0800 (PST)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 D4AB21ACD5D for <trans@ietf.org>; Wed, 24 Feb 2016 06:17:05 -0800 (PST)
Received: by mail-yw0-x22b.google.com with SMTP id u200so15875450ywf.0 for <trans@ietf.org>; Wed, 24 Feb 2016 06:17:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=x5Lhy3HMU/SHWQo1WHZSqyHu91OGey7/et4CxipfA+k=; b=e9OtLlbWOAuuOLv/4TV+EveyYCKlRL/pzwvBhtMJxZeyUFeXd/ItG6Kixqfe6FgxSk 1xIvh8+BdjzjZ7wzE43LsTeBNFxBEbaFnaX8ObVGfolGExW/H2bppBiiqllkVW73jDPS K7SDcSC1fDpKa8BTXOoUGVCTZsVpeGa0co+g4=
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:from:date :message-id:subject:to:cc:content-type; bh=x5Lhy3HMU/SHWQo1WHZSqyHu91OGey7/et4CxipfA+k=; b=Ik/4ncs77x+4s0B14/zkr7PSOWjdiBl53SbmrpKO3nf8KQp7hIwykOUG2vmhtxycjL w1Ml9JzVh/ghklXMy8GJfuCKMK01XiA2nVaDAY/4BZawukGrewzG+J90O6oQ0A8UXheT Gm8QtBKo9AO2tbvbg5Iy8/EMQ15d2ZJL8mGyMaA+KcsnSs9uUKQEp777dP2eZlXDe9QF 7Z4h7Druooe9cwCkn90zovUTxs7gOKZMPA5WK1+ujROabzEkiB7Sj3u1FNky6w7dYsAS Rfd1JBfOIanVgB437SiWUegcNJH3QsTfspjx+rQF7R3PRXANVFKOOOtlqZ6J+s2Lszov Al6Q==
X-Gm-Message-State: AG10YOQZTwmzjnFlxjMudpaxLCwsy9UeBH2PhkUVSxX+c5KG22VS3YpCM9avC3QMRb2x6SEx4Gftylr9Y3qoliwt
X-Received: by 10.129.72.18 with SMTP id v18mr23307464ywa.228.1456323425128; Wed, 24 Feb 2016 06:17:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.48.214 with HTTP; Wed, 24 Feb 2016 06:16:45 -0800 (PST)
In-Reply-To: <56CD91F0.2090705@comodo.com>
References: <87io1i3gqw.fsf@alice.fifthhorseman.net> <CABrd9SQh5B8E8phCvgLdUntKBu=u4p2iUHJ7ZrjqMwz8edwLHA@mail.gmail.com> <56CAF5B2.30207@comodo.com> <CA+cU71m7akWkLFPiTVOShuTBHLVWfA+Byw2vXF-AZtH0Byik5A@mail.gmail.com> <56CC373C.30201@comodo.com> <56CD91F0.2090705@comodo.com>
From: Tom Ritter <tom@ritter.vg>
Date: Wed, 24 Feb 2016 08:16:45 -0600
Message-ID: <CA+cU71kPAdZ=6eK4tb11mSRjNxeyt279t6xCGEGfdvcb2X_0og@mail.gmail.com>
To: Rob Stradling <rob.stradling@comodo.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/wb_MKQiEitskxDWuyXsbTa9HeMk>
Cc: "trans@ietf.org" <trans@ietf.org>, Ben Laurie <benl@google.com>, 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: Wed, 24 Feb 2016 14:17:08 -0000

Not interleaving this time, but batch-replying:

On 23 February 2016 at 04:41, Rob Stradling <rob.stradling@comodo.com> wrote:
> On 23/02/16 06:03, Tom Ritter wrote:
> <snip>
>>>
>>> [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.
>
>
> SCTs in 6962-bis already contain the issuer_key_hash (which is the DER
> encoding of the issuer's SubjectPublicKeyInfo).  Is that enough to defeat
> your trick key attack?

Yes.

>>> [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...?
>
>
> For Win2K and WinXP, it appears that it only attempts name matching if the
> AKI extension is absent.
>
> "If there is no information in the AKI, or the AKI does not exist in the
> certificate being evaluated, a certificate whose subject name matches the
> evaluated certificate's issuer name will be chosen. This selection method is
> known as a name match."
> https://technet.microsoft.com/en-us/library/cc700843.aspx

That's beneficial for our purposes though.

> <snip>
>>>
>>> [Rob]
>>>    - say that TLS clients SHOULD fetch and verify inclusion proofs for
>>> all
>>> intermediate certs that they rely on.
>>
>> I'm nervous about this.
>
> Why so?  I wasn't suggesting a "MUST".  ;-)

What's the risk to clients who don't?

Currently, in gossip clients who don't want to fetch proofs (because
it's unacceptable to them privacy-wise or whatever) can use SCT
Feedback. (If they talk to a site that doesn't use SCT Feedback, then
they're sunk, but we hope this and other incentives will encourage
uptake of SCT Feedback.)

Because the say the client MUST submit the full chain in SCT
Feedback... I think SCT Feedback does actually cover the clients who
don't get the inclusion proof for the intermediate.  And it would be
simple enough to add the SHOULD to STH Pollination to grab a STH for
the intermediate cert and pollinate that. So now I'm less worried.


On 23 February 2016 at 05:06, Ben Laurie <benl@google.com> wrote:
> On 23 February 2016 at 06:03, Tom Ritter <tom@ritter.vg> wrote:
>> 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?

This is a good walkthrough:  http://crypto.stackexchange.com/q/8902



On 23 February 2016 at 19:59, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> On Tue 2016-02-23 03:06:25 -0800, Ben Laurie wrote:
>> Fair point. At least two ways of doing this:
>>
>> a) Run a log that is not trusted for HTTPS connections.
>
> (trolling: i thought logs didn't have to be trusted...)
>
> what encourages any party in the ecosystem to log in this untrutsed log?

Technically we don't need CAs to log to that log, the community can
log to it. Google Crawler, the EFF's Distributed HTTPS Observatory,
Firefox plugins, replication from other logs...




On 24 February 2016 at 05:20, Rob Stradling <rob.stradling@comodo.com> wrote:
> Actually, issuer_key_hash is already included in the
> TimestampedCertificateEntryDataV2 structure from which leaf hashes are
> calculated.  I think that's sufficient to guard against inclusion proofs
> being considered valid in conjunction with a trick issuer public key (but
> please correct me if I'm wrong!)

To be 100% honest I have not tracked -bis as closely as I should have.
So I need to take a pass through gossip and make sure that the types
of things I expect 'intuitively' from bis align with what it provides.