Re: [Trans] DNSSEC also needs CT

"Osterweil, Eric" <eosterweil@verisign.com> Thu, 22 May 2014 17:32 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 EBF8F1A023D for <trans@ietfa.amsl.com>; Thu, 22 May 2014 10:32:43 -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 GeCB2i-pvJou for <trans@ietfa.amsl.com>; Thu, 22 May 2014 10:32:42 -0700 (PDT)
Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63ED1A01C2 for <trans@ietf.org>; Thu, 22 May 2014 10:32:41 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKU340uJmbpap4Mh9uvmUk5zaNrJ70u8l8@postini.com; Thu, 22 May 2014 10:32:40 PDT
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s4MHWdBV008179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <trans@ietf.org>; Thu, 22 May 2014 13:32:39 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 22 May 2014 13:32:39 -0400
From: "Osterweil, Eric" <eosterweil@verisign.com>
To: "trans@ietf.org" <trans@ietf.org>
Thread-Topic: [Trans] DNSSEC also needs CT
Thread-Index: AQHPa84LSH1SIX2llEKvVF71u2zhO5tNMA6AgAADCgA=
Date: Thu, 22 May 2014 17:32:38 +0000
Message-ID: <1C7BC1B3-B792-43F4-BC8F-C75FC8965B6E@verisign.com>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <537E3229.4070402@bbn.com>
In-Reply-To: <537E3229.4070402@bbn.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=_EF12A61A-9F51-4CE6-918E-0A6B3818FF17"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/w078YCOxUY6QtylfLIm5_ep9cDg
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:32:44 -0000

On May 22, 2014, at 1:21 PM, Stephen Kent <kent@bbn.com>
 wrote:

> Nico,
>> 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.
>> It follows that things like CT that we're applying to PKIX should be
>> applied to DNSSEC as well, where possible.
> maybe.
>> I don't see any reason why CT couldn't be extended to DNSSEC.  IMO, it
>> should be done.
> I'll defer to DNS experts on that.

Without implying an presumption of expertise on DNS, I would argue that DNSSEC avoids the problems CT seems to be trying to solve by coupling its key learning (and verification) methods to the hierarchical namespace.  As Steve said (I believe) PKIX != Web PKI, and the problems addressed by CT seem to be focused more on the latter.  I don't think there is a key learning/verification dilemma in DNSSEC that CT is appropriate for.

Eric