Re: [Trans] DNSSEC also needs CT

Phillip Hallam-Baker <> Thu, 22 May 2014 17:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1258F1A0259 for <>; Thu, 22 May 2014 10:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QDeCutBu15w5 for <>; Thu, 22 May 2014 10:32:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDC3E1A024B for <>; Thu, 22 May 2014 10:32:58 -0700 (PDT)
Received: by with SMTP id m15so3739589wgh.20 for <>; Thu, 22 May 2014 10:32:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=I52WWhD4uYf2KrVy66eVjVNF1xIXK2uniaZUQ0qGkos=; b=ecMVZBoFScXuKS1MTWLh3tOOx55YemiTwxoQ2ZaDvXxfl+PAxUAJu7pqMl5MkjRqjG aJ6i6prX8BBbSQAt/AulHITcG/ZXErA18oDLCC1i+nOGhFWcYOTP/vm/lfoGonCXP2v1 DRemrH9RwlACex1FmEOQCopRkuINwoBeIVeQCLHfI0icu79oEKiYuQtjg9p6EhCn2Uaw UiHknN0oyM56xUosYU0FHwCxBOuYISQmRvTLCZ4sj67iy0WdxzO28y2xUmsCsaFyOK2E p5B1ojGIC0l7ndEYJ3i0YVNvWPwtcZ+6xXn0zF555ZQevudT4iW3fITyTRQOK9qwKimA IGXA==
MIME-Version: 1.0
X-Received: by with SMTP id fc6mr17446098wib.59.1400779976348; Thu, 22 May 2014 10:32:56 -0700 (PDT)
Received: by with HTTP; Thu, 22 May 2014 10:32:56 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 22 May 2014 13:32:56 -0400
X-Google-Sender-Auth: wpSxivotOSyUtJ04_JXxHyc9p-M
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Stephen Kent <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [Trans] 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: Thu, 22 May 2014 17:33:00 -0000

On Thu, May 22, 2014 at 1:21 PM, Stephen Kent <> wrote:

> PKIX, per se, does not have the trust problems that seem to motivate
> CT; the Web PKI does. That PKI has always had a serious problem because
> any TA can issue a cert for any Subject, irrespective of the Subject name.
> because DNSSEC intrinsically incorporate the equivalent of PKIX Name
> Constraints, it does not suffer from that specific problem. That's not to
> say that mis-issuance is not possible in DNSSEC, but rather that its
> effects are more limited.

On the contrary, it has a rather more severe problem in that the names
can be reassigned by the upstream zone.

Depending on your application, this might not matter. But if you want
to try hooking an enterprise PKI off a DNSSEC system then this matters
a great deal. I am sure that Google would not want to find that
VeriSign could direct their infrastructure to change configuration by
issuing a fraudulent DNSSEC signed zone.

Come to that, that particular sort of compromise is the type of thing
that we spent a lot of time and effort trying to put out of reach when
I worked at VRSN. I don't want to have someone's private key because I
don't want to be accused of losing it.

Don't think of CT in this case being something to solve a problem
faced by DNSSEC users, instead think of it as something that enables
use for problems where it is otherwise unsuited.

The other major advantage is that it provides a tool to avoid some of
the cryptographic lock in problems that are causing certain countries
to cause issues in ICANN. You don't have to agree with their analysis
to find value in addressing the concerns.