Re: [Trans] DNSSEC also needs CT

"Osterweil, Eric" <eosterweil@verisign.com> Thu, 22 May 2014 17:47 UTC

Return-Path: <eosterweil@verisign.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9261A0236 for <trans@ietfa.amsl.com>; Thu, 22 May 2014 10:47:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HCdrix0CiKy for <trans@ietfa.amsl.com>; Thu, 22 May 2014 10:47:24 -0700 (PDT)
Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225031A01C2 for <trans@ietf.org>; Thu, 22 May 2014 10:47:23 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKU344KbR3GBuzHA6IBAT1qa48OLjHcya2@postini.com; Thu, 22 May 2014 10:47:22 PDT
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (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 BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 22 May 2014 13:47:20 -0400
From: "Osterweil, Eric" <eosterweil@verisign.com>
To: Nico Williams <nico@cryptonector.com>
Thread-Topic: [Trans] DNSSEC also needs CT
Thread-Index: AQHPa84LSH1SIX2llEKvVF71u2zhO5tNMA6AgAAEtQCAAAJuAA==
Date: Thu, 22 May 2014 17:47:19 +0000
Message-ID: <8952DCE6-37BA-4063-8D6F-D061E9D50194@verisign.com>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <537E3229.4070402@bbn.com> <CAK3OfOjhJZut5tKNtcR-FPG5Q-M6QXbTzEP_6WdYbRVTpt970w@mail.gmail.com>
In-Reply-To: <CAK3OfOjhJZut5tKNtcR-FPG5Q-M6QXbTzEP_6WdYbRVTpt970w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: multipart/signed; boundary="Apple-Mail=_AECFFB06-05E8-4912-8AED-F2E3F03638D3"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5aOiuhce0PiUmHl39xXiYL5-C0o
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] DNSSEC also needs CT
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 17:47:25 -0000

On May 22, 2014, at 1:38 PM, Nico Williams <nico@cryptonector.com>
 wrote:

> On Thu, May 22, 2014 at 12:21 PM, Stephen Kent <kent@bbn.com> 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

Eric