Re: [Trans] DNSSEC also needs CT

"Osterweil, Eric" <> Thu, 22 May 2014 17:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AE9261A0236 for <>; Thu, 22 May 2014 10:47:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6HCdrix0CiKy for <>; Thu, 22 May 2014 10:47:24 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 225031A01C2 for <>; Thu, 22 May 2014 10:47:23 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Thu, 22 May 2014 10:47:22 PDT
Received: from ( []) by (8.13.6/8.13.4) with ESMTP id s4MHlKV8008668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 May 2014 13:47:21 -0400
Received: from ([::1]) by ([::1]) with mapi id 14.03.0174.001; Thu, 22 May 2014 13:47:20 -0400
From: "Osterweil, Eric" <>
To: Nico Williams <>
Thread-Topic: [Trans] DNSSEC also needs CT
Thread-Index: AQHPa84LSH1SIX2llEKvVF71u2zhO5tNMA6AgAAEtQCAAAJuAA==
Date: Thu, 22 May 2014 17:47:19 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_AECFFB06-05E8-4912-8AED-F2E3F03638D3"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
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:47:25 -0000

On May 22, 2014, at 1:38 PM, Nico Williams <>

> On Thu, May 22, 2014 at 12:21 PM, Stephen Kent <> wrote:
>>> DNSSEC is a PKI [of sorts; please, no need to pick nits about that].
>> agreed.
>>> It stands to reason that DNSSEC should have similar trust problems as
>>> PKIX.  I believe it does indeed.
>> 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.
> I've already said that DNSSEC fundamentally has strong naming
> constraints, whereas the TLS web server PKI doesn't (and worse: has
> been deployed with none).
> However, I don't think it necessarily follows that having name
> constraints -> no need for CT.
> CT is about keeping CAs honest.  In the TLS web server PKI there are
> very many CAs to keep honest, therefore anything that helps automate
> that task is greatly helpful.
> DNSSEC "CAs" also could use being kept honest, even if none of them
> have yet failed to be honest.

If I understand your point (perhaps I don't) the type of ``honest[y]'' that you are talking about (in the Web PKI) refers to a CA vouching for a name binding that is illegitimate. How do you imagine this is possible in DNSSEC?  I could (for example) stand up a DNSSEC signed zone for someone else's zone, but because key verification and key learning are tied to the DNS delegation hierarchy, no resolver would learn of my doppelgänger zone, right