Re: [Trans] DNSSEC also needs CT

Phillip Hallam-Baker <> Sun, 11 May 2014 15:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 665771A0258 for <>; Sun, 11 May 2014 08:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7DvXe0ztYL3C for <>; Sun, 11 May 2014 08:20:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22e]) by (Postfix) with ESMTP id E99861A0259 for <>; Sun, 11 May 2014 08:20:23 -0700 (PDT)
Received: by with SMTP id n12so5911503wgh.29 for <>; Sun, 11 May 2014 08:20:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lA5XAm0f8cQP9lf+J3mf2zBQu4Ql/RmmjWqv4p+bb3g=; b=PdmzUo9GxtguYroTNAFXkRYLx/rXzJdz1Su/NAE2D2YU4mlHPrvkuGPS45wNiVLTx2 2OQo0xnzsEjCIa2fwZt9NLjdqJkZ+7c3Tuso6EJaBvr5XCyalbTtuVnquxoMk8j4qdx1 H0H0kyCSodSa7QFnNoxK4+GCRxcg70aHNFp2mRzvYXUmfgCg7O0bUquI7nYyUGRk3aUv s1bUb9uyeD3i06PKS0ZEihxpEsyKa8i4nxkZ8N3ptFQ+j90XYau3sNBVGN0CE9/5FxJr pojnNHjPEtem0Ne/6SOOCSF7B3ooLZQ4cnsxLHlLtHKOihJC2DT0Yu0cZzn0Aql3wmy8 BQmg==
MIME-Version: 1.0
X-Received: by with SMTP id gk8mr11759124wib.32.1399821617801; Sun, 11 May 2014 08:20:17 -0700 (PDT)
Received: by with HTTP; Sun, 11 May 2014 08:20:17 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Sun, 11 May 2014 11:20:17 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Daniel Kahn Gillmor <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>, Paul Wouters <>, Warren Kumari <>
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: Sun, 11 May 2014 15:20:31 -0000

What I think this discussion is really uncovering is that we don't
really have a model for how CT is applied to WebPKI certificates. All
the questions raised in the DNSSEC discussion seem to be predicated on
assumptions as to how CT logs are managed that are outside the spec.

Which is why having the DNSSEC discussion now is useful. I don't like
specs that are based on unwritten assumptions. That leads to a
situation where implementations have to understand folklore.

In particular, does CA = log maintainer?

For DNSSEC there seem to be a lot of unnecessary assumptions being
made. I certainly don't think everyone wants to run their own CT log
for DNSSEC. And there would be little value in the scheme if they did.
The value of a CT log depends in part on aggregation.

Another unnecessary assumption is that any log maintainer would have
to be a CABForum member. Membership in the forum has no impact on root
inclusion or CT. The only requirement for root inclusion is acceptance
by the root maintainer, most of which adopt the CABForum EV and BR
criteria. The most important part there being audit.

It is probably fair to assume that CT logs will be maintained by CAs
but it would be entirely practical for an open service to be
established. The criteria are rather simpler to enforce than
certificate issue.

It might or might not be desirable to require some sort of certificate
chain to some sort of root. But any such chain does not need to be the
only validation chain PKIX supports cross certificates and an
end-entity certificate may be legitimately accredited to multiple

The main question is what purpose a CT log for DNSSEC would serve. For
me the value would be to protect my domain against having it stolen by
ICANN. The idea that we should put trust or faith in an organization
extorting $250,000 for domains is ridiculous. And so is the fact that
IESG members have told me that they don't think they should make that
kind of comment even if true because of 'politics'.

If you don't like your WebPKI CA then you can get another. And that
means the costs are competitive. But ICANN has a monopoly and a rent
seeking management.

Deploying CT to establish an independent claim on the domains makes
perfect sense.