Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME

Ben Laurie <ben@links.org> Thu, 23 October 2008 11:05 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14D328C1A8; Thu, 23 Oct 2008 04:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
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 1LbegT8PF6YN; Thu, 23 Oct 2008 04:05:38 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFDB228C199; Thu, 23 Oct 2008 04:05:12 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Ksxv6-000DbI-Mq for namedroppers-data@psg.com; Thu, 23 Oct 2008 11:00:00 +0000
Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <ben@links.org>) id 1Ksxuu-000DZO-6P for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 10:59:55 +0000
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 8498133C1F; Thu, 23 Oct 2008 12:01:11 +0100 (BST)
Message-ID: <49005921.2090108@links.org>
Date: Thu, 23 Oct 2008 11:59:45 +0100
From: Ben Laurie <ben@links.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: Michael StJohns <mstjohns@comcast.net>
CC: namedroppers@ops.ietf.org
Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME
References: <Your message of "Mon, 22 Sep 2008 15:12:44 -0400." <E1KhqqB-000CE1-QD@psg.com> <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <E1Khwdp-000J3V-QJ@psg.com> <a06240804c4ffc42abc16@[10.122.105.108]> <E1KicTm-000ANO-PO@psg.com> <a06240800c50fd3decd5b@[192.168.1.101]> <48F2DE42.1060209@links.org> <E1KpLkt-000HQ3-Is@psg.com> <48F33C34.3010901@nlnetlabs.nl> <D3AA46B662F334B8639E08CF@Ximines.local> <48F35170.30900@links.org> <4B27E2458EBA97669B259355@Ximines.local> <a06240800c5190d86422c@[192.168.1.101]> <STNTEXCH12OdHa24ABv00004495@stntexch12.cis.neustar.com> <a06240805c5193b226886@[10.31.201.38]> <48F3B11B.8090202@links.org> <a06240803c51a5b57d9fa@[192.168.1.101]> <A5A466C8-E774-4331-A63F-6C38778DECD3@icsi.berkeley.edu> <E1KsoTF-000GYV-PY@psg.com>
In-Reply-To: <E1KsoTF-000GYV-PY@psg.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

Michael StJohns wrote:
> After thinking about this topic for a while, I'm still bothered by
> the inconsistency of treatment here.
> 
> But I think I have a possible mechanism - at least for DNAME.
> 
> DNAME is the pretty much the equivalent of a delegation - only
> sideways.    Why not treat it like any other delegation?  In other
> words, in addition to the records currently permitted at a DNAME
> node, add DS to the list.  This would require slightly overloading
> the meaning of DS, but in a way that doesn't break the model too
> much.
> 
> If a DNAME node does not have at least one corresponding DS record
> (proven by NSEC/NSEC3), the validation rules are exactly the same as
> if you'd not included a DS for a subordinate delegation. E.g. no
> DNSSEC is expected in the target zone.
> 
> Since one of either DNAMEs or NS records can be present at a node (I
> think that's correct), the interpretation of the DS record is
> dependent on which of these two is present.  If the type is DNAME,
> the DS record points to a DNSKEY record at the target name and the
> chain has to continue from there.
> 
> This gets away from the problem where a resolver has one trust
> anchor, but doesn't have a trust anchor for the target zone at the
> cost of requiring some administration of the DS at the DNAME.
> 
> Continuing the logic from above, if you get a unsecure DNAME
> delegation (i.e. DNAME without DS), you *stop* doing DNSSEC
> validation.  It doesn't matter if you have trust anchors for any
> further targets - the validation answer is UNSECURE.  This is
> required for consistency - different resolvers have different sets of
> trust anchors.  It's not all that coherent to get BOGUS from one,
> UNSECURE from another and UNKNOWN from a third if you can avoid it.
> Chaining security back to the original trust anchor and evaluating
> security in terms of data that chains back ONLY to that trust anchor
> seems to be the most consistent approach.
> 
> In any event, I think this is at least somewhat backwards compatible.
> 
> 
> Let the mud slinging begin... :-)

I don't understand the rationale behind all this complication.

If I chose to point a DNAME at an unsecured domain, then that was my
choice, and I should live with it. If I don't want the domain to be
unsecured, then I should either not delegate to it, or ensure it is
secured by non-protocol means (e.g. by owning the domain myself, by
contract, by sufficient purchase of beer for the domain owner, etc.)

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>