Re: [Trans] On the worthiness of DNSSEC and PKI (Re: DNSSEC also needs CT)

Tao Effect <> Sat, 10 May 2014 00:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D7BFC1A013A for <>; Fri, 9 May 2014 17:31:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.334
X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 e-c4dXZDpMuC for <>; Fri, 9 May 2014 17:31:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 16A781A0114 for <>; Fri, 9 May 2014 17:31:50 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 35BC63BC06A; Fri, 9 May 2014 17:31:45 -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=dAqICtFduTK6wfiOb hwUwakWM8k=; b=ZxuXR0G3JJ4g4AuDdx+3n/zSwGq/OsdSGA5pPkYoeB1VvmRY9 ntYuHX85oWBFFBQofHbG1+KQqJNYXl/Sk06DlFGHpoM/sudYI0EsdPRwPhISDyqB w2YpVE706xEdlSRAProVSeqYD9QiMvR9XPwv/m8LRLZYjXwLAMnRpgfu7s=
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 3BAAE3BC059; Fri, 9 May 2014 17:31:43 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_54E551C7-B4EA-41A5-BF81-465E82370333"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Pgp-Agent: GPGMail 2.1 (525b9ae)
From: Tao Effect <>
In-Reply-To: <>
Date: Fri, 09 May 2014 19:31:41 -0500
X-Mao-Original-Outgoing-Id: 421374701.157575-34bc64d8fc668f0d9b1e0e09799a1a5b
Message-Id: <>
References: <>
To: Nico Williams <>
X-Mailer: Apple Mail (2.1874)
Cc: "" <>, "Mehner, Carl" <>
Subject: Re: [Trans] On the worthiness of DNSSEC and PKI (Re: DNSSEC also needs CT)
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, 10 May 2014 00:31:52 -0000

On May 9, 2014, at 6:50 PM, Nico Williams <> wrote:
> That's all I'll do for now.  I don't have time to engage your position
> at this time.

As you say, noted.

> Surely others already have anyways.

Actually not really, this email, and the randombit thread that I linked to (which didn't get a reply), has been about it.

Part of the reason, I think, is because I haven't really spelled out in detail what the problems with CT are, just alluded to them, which may make it easy for folks to dismiss the comments as "he doesn't know what he's talking about."

It's something I just need to find the time to do.

> By "noted" I meant to say that yes, I took note of your position but I
> don't want to discuss that topic in the context of "DNSSEC needs CT"
> -- the two matters are separable.  To discuss your response in the
> same thread would just create noise.  At any rate, I don't have time
> to address it separately anyways.  Feel free to educate us though.

The fact that the folks on this list are supposed to be CT specialists makes it easier for me to write very brief critiques (without having to explain the details of how CT works).

CT is X.509 on steroids, and I mean that in the most negative of ways possible.

The crux is just this then:

CT makes X.509 even more complicated than it already is. This inherently makes it less secure than even today's already totally insecure X.509 system (more moving parts).
CT does not prevent Man-in-the-Middle (MITM) attacks. Given that the purpose of CT is supposedly to protect from such attacks, this is embarrassing and shameful.
Expanding on 2: CT takes today's PKI and divides it up into "The Server" (the NSA), "The CA" (the NSA), and "The Log Server" (the NSA). This is how MITM works, it doesn't matter if the NSA doesn't actually own those servers because they effectively do by controlling the network itself.
Clients have no way of detecting a MITM attack because the RFC gives them no such powers. If this complicated system were implemented perfectly, then most of the security rests not on the log servers, but on the "gossip protocols" that the RFC alludes to but does not describe. These protocols are supposed to be described in other documents, but as far as I'm aware they do not exist. Nor is any hint given as to their feasibility or to how the gossip channels themselves will be protected from MITM.
CT centralizes security into the hands of a limited amount of CAs and Log Servers that must be trusted by everyone on the internet. It explicitly excludes support for self-signed certificates, ensuring lots and lots of $$$$ for those that run those servers, making todays pay-for-insecurity system even worse than it is. It effectively takes the security of the entire internet for ransom and puts it into the hands of government intelligence agencies and anyone else with MITM capabilities.
CT does not actually care about preventing MITM attacks and places the burden of detecting such attacks squarely on the shoulders of domain owners and individuals. Attacks will happen successfully CT explicitly takes no steps to stop them as they happen.
CT's very existence distracts the internet from real solutions that actually prevent MITM attacks, are far simpler, and provide security to everyone for ~$0. This alone makes it a significant threat to global security.

Maybe I'll post a more detailed version of this later (with citations, illustrations, etc.). But seeing as this is a technical list, I hope it will do for now.

Greg Slepak

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