Re: [keyassure] Asserting DANE exclusivity for an entire domain

Olafur Gudmundsson <ogud@ogud.com> Mon, 28 March 2011 12:55 UTC

Return-Path: <ogud@ogud.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321673A6A76 for <keyassure@core3.amsl.com>; Mon, 28 Mar 2011 05:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.429
X-Spam-Level:
X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjH0iBwFDIcb for <keyassure@core3.amsl.com>; Mon, 28 Mar 2011 05:55:11 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 87FCB3A6A81 for <keyassure@ietf.org>; Mon, 28 Mar 2011 05:55:11 -0700 (PDT)
Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p2SCulK7051231 for <keyassure@ietf.org>; Mon, 28 Mar 2011 08:56:48 -0400 (EDT) (envelope-from ogud@ogud.com)
Message-ID: <4D908590.5020302@ogud.com>
Date: Mon, 28 Mar 2011 08:56:48 -0400
From: Olafur Gudmundsson <ogud@ogud.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: keyassure@ietf.org
References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <1296657079.1889.8.camel@mattlaptop2.local> <m3lj1ykvav.fsf@jhcloos.com> <1296688716.2621.20.camel@mattlaptop2.local> <m3zkqdhxsm.fsf@jhcloos.com>
In-Reply-To: <m3zkqdhxsm.fsf@jhcloos.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Mar 2011 12:55:14 -0000

On 03/02/2011 11:45 AM, James Cloos wrote:
>>>>>> "MM" == Matt McCutchen<matt@mattmccutchen.net>  writes:
>
>>> Since we rely on DNSSEC anyway, DS records are the ideal way to
>>> determine zone cut points.  They are grabbed anyway as a matter
>>> of course and provide all the clue required.
>
> MM>  Right... but do DNSSEC client libraries make it easy to access this
> MM>  information without doing a separate query for the DS record?
>
> Even if they do not, the resolver had to grab the DS as part of the
> validation, so the round trip for an extra DS lookup by the end client
> is by definition local, often even same-process.
>
> -JimC

Actually the RRSIG(DTLS) is an even better indicator the zone name ==
signer name, there is no need to look up the DS record from the client.

	Olafur