Re: [Trans] Threat model outline, attack model

Tao Effect <> Sat, 27 September 2014 05:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8FF491A8790 for <>; Fri, 26 Sep 2014 22:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.066
X-Spam-Status: No, score=0.066 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q9YJ45eTVGfJ for <>; Fri, 26 Sep 2014 22:05:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C82631A1B8D for <>; Fri, 26 Sep 2014 22:05:10 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 865E9392070; Fri, 26 Sep 2014 22:05:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to;; bh=d0pVHtxh+zYKClNBM tN0GeiFuA4=; b=ZnPMz9BCcKChd9dHVEgWkUzU74MMOCLkU/EioRvqSCBmN9zF/ vf0AKQPzNsWrNl4kznYXR9c6oSfaG9pFSEWTrVbWTOviyeKfq3qo0UtYiwonzXuz hiRIWhyWZJbpFG0Y6Vi3j/5H05AySyYHZ6dtMuf3fJ4hUrS/Y2SAX3IhwQ=
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 1698D39206D; Fri, 26 Sep 2014 22:05:09 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_EDEC5E4A-1EEA-4B46-A070-DA4F1AC972F8"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Pgp-Agent: GPGMail 2.1 (f76fd85)
From: Tao Effect <>
In-Reply-To: <>
Date: Fri, 26 Sep 2014 22:05:09 -0700
X-Mao-Original-Outgoing-Id: 433487108.881293-6e9e3ec6d526201172d5d1732dd805a6
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Paul Wouters <>
X-Mailer: Apple Mail (2.1878.6)
Subject: Re: [Trans] Threat model outline, attack model
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 27 Sep 2014 05:05:13 -0000

Dear Paul,

On Sep 26, 2014, at 7:38 PM, Paul Wouters <> wrote:

> It would be even better it you would be part of the discussion here on
> the trans working group to ensure the gossip protocol is implemented
> in a way that is secure and useful to everyone, including yourself.

That's very kind of you to invite me to the discussion, so I spent some time just now thinking about how to do gossip right.

To start, I re-read the most recent document I have on gossip:

Then something occurred to me: for some reason, perhaps because of how complicated the details of CT are, I hadn't realized that I was wrong about something, that now seems obvious. In my blog post, I'd written:

At its core, it introduces the concept of an append-only auditable log that is guaranteed to show the most recently issued SSL cert for any given domain (IF you’re able to ask it).

That is actually not true (for Auditors).

So then I re-read parts of Steve's original post in this thread that I had skipped. Indeed, there it was in his "Notes", the same thing I just now realized (he really did a fantastic job):

1. If a CA submits the bogus certificate to logs, but these logs are not watched by a Monitor that is tracking the targeted Subject, CT will not mitigate a mis-issuance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests its certificates be monitored. Absent such a guarantee, how do TLS clients and CAs know which set of Monitors will provide “sufficient” coverage. Unless these details are addressed, use of CT does not mitigation mis-issuance even when certificates are logged.

For Auditors, it doesn't mitigate mis-issuance even for *the same* log. I.e., a rouge CA/log combo (let's just call them "Clogs" :P) is free to step in, create a fraudulent certificate, use it for MITM, and then restore the original, undetected even by Auditors that successfully gossip STHs! For the same log!

The only ones who can stop this are Monitors, since they are able to request everything that's in the Clog and verify for themselves that there aren't any fraudulently issued certs.

And this, my friends, is Game Over.

I see no way that Monitors can save us here, even with successful gossip of STHs.

To save us, Monitors would need to monitor *all* logs for *all* domains and somehow successfully get this information to people who are being attacked with a fraudulent certificate.

Sorry, I tried, and in trying, I've realized that CT is more broken than I originally thought. I have no recommendations to give (except ones that you've heard already, and are likely "off topic" on this list).


Kind regards,
Greg Slepak

Please do not email me anything that you are not comfortable also sharing with the NSA.