Re: [Trans] DNSSEC also needs CT

Stephen Kent <> Mon, 02 June 2014 17:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 49D701A01ED for <>; Mon, 2 Jun 2014 10:12:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.152
X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T5xP-r3fNkLS for <>; Mon, 2 Jun 2014 10:12:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 80F6B1A007B for <>; Mon, 2 Jun 2014 10:12:09 -0700 (PDT)
Received: from ([]:51199 helo=comsec.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1WrVmE-000P4I-T5; Mon, 02 Jun 2014 13:12:03 -0400
Message-ID: <>
Date: Mon, 02 Jun 2014 13:12:01 -0400
From: Stephen Kent <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Phillip Hallam-Baker <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Mon, 02 Jun 2014 17:12:11 -0000



>> is that really more "serve" than an ability to issue a credential
>> for ANY name, as in the Web PKI?
> At least that is a temporary condition.
If CT is successful, yes.
> Any trust infrastructure that ultimately rests on the common sense of
> the US Congress and President is doomed in the long run. And there
> isn't a better political solution on offer either.
common sense an the U.S. Congress, that's an uncommon pairing :-).
> Finding a technical mechanism that reduces the dependence on the
> political/policy dimension makes it much easier to address that layer.
> If it is possible it is always far easier to eliminate a single point
> of failure than to work out policy level controls to prevent abuse.
> ...
> If they already have a PKI then they are probably not interested in
> DNSSEC at all because that problem is already solved and DNSSEC is the
> red herring.
agreed, unless someone convinces them that the shiny new DNSSEC approach
to PKI is better, ...
> Unless that is there is an interesting way to use DNSSEC as an
> extension of the enterprise PKI. In which case it is critical that the
> DNSSEC PKI does not introduce a new point of failure.

That's a very confusing last phrase.

> DNSSEC is still raw technology. Saying that it does not need feature X
> before the full set of potential applications is premature. We don't
> know what it is useful for yet. That is what we should find out.
Thanks for the clarification.
>> I understand their concerns. But the lack of a well-articulated architecture
>> for CT, much less a CT for DNSSEC, makes it hard for me to gauge whether
>> this is a good idea.
> I find that looking at an additional field of application is often a
> very good way to improve an underspecified architecture.
I guess so, but I'd really prefer a fully-specified architecture for
what purports to be the motivating case, before we claim its a good
basis for solving other problems. I think the potential DNSSEC mis-issuance
problems are different enough to merit a separate analysis and design 
> Trans is rather too closely designed to solve one problem and it is
> not even clear that it does that particularly well. There is a lot of
> fuzziness in the process by which a relying party decides that a
> particular value is the true Merkle tree apex of a particular log.
I agree.