Re: [Trans] DNSSEC also needs CT

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 22 May 2014 18:01 UTC

Return-Path: <dkg@fifthhorseman.net>
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 7C3941A028D for <trans@ietfa.amsl.com>; Thu, 22 May 2014 11:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 QWxvC7rQb0em for <trans@ietfa.amsl.com>; Thu, 22 May 2014 11:01:27 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5EE1A0276 for <trans@ietf.org>; Thu, 22 May 2014 11:01:15 -0700 (PDT)
Received: from [10.70.10.78] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id D7C03F984; Thu, 22 May 2014 14:01:10 -0400 (EDT)
Message-ID: <537E3B5A.8090808@fifthhorseman.net>
Date: Thu, 22 May 2014 14:00:58 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: "Osterweil, Eric" <eosterweil@verisign.com>, Nico Williams <nico@cryptonector.com>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <537E3229.4070402@bbn.com> <CAK3OfOjhJZut5tKNtcR-FPG5Q-M6QXbTzEP_6WdYbRVTpt970w@mail.gmail.com> <8952DCE6-37BA-4063-8D6F-D061E9D50194@verisign.com>
In-Reply-To: <8952DCE6-37BA-4063-8D6F-D061E9D50194@verisign.com>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="aSun3IqLfTgx9fSBEQEgevxmdXvCNchFB"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/AdmHWoprEa2RBWwb-JPcfOKcL9A
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 18:01:32 -0000

On 05/22/2014 01:47 PM, Osterweil, Eric wrote:
> 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

if i control zone foo.bar.example, and you control my parent zone
(bar.example), you can do the following:

 * make a new zone-signing key X

 * stand up an "authoritative" server for the foo.bar.example zone,
signed by X, with a DNSKEY record for X.

 * serve the appropriate DS record in the parent zone (bar.example) to
delegate foo.bar.example to X instead of the correct ZSK.

I'd very much like to know if you've ever done this rather than
publishing the correct DS.

DNSSEC-for-CT seems like one approach to be able to detect this kind of
misissuance.

	--dkg