Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME
Michael StJohns <mstjohns@comcast.net> Thu, 23 October 2008 16:42 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 567D63A6A0A; Thu, 23 Oct 2008 09:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.269
X-Spam-Level:
X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[AWL=-0.832, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=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 5HkKJZ0ZCLs2; Thu, 23 Oct 2008 09:42:13 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 284053A6930; Thu, 23 Oct 2008 09:42:13 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Kt3CK-000MoD-67 for namedroppers-data@psg.com; Thu, 23 Oct 2008 16:38:08 +0000
Received: from [76.96.30.32] (helo=QMTA03.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <mstjohns@comcast.net>) id 1Kt3Bw-000Mkh-Sh for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 16:37:49 +0000
Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id WA8V1a0020cQ2SLA3GdjQb; Thu, 23 Oct 2008 16:37:43 +0000
Received: from MIKES-LAPTOM.comcast.net ([68.48.0.197]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id WGdg1a00S4F1VyU8WGdhsU; Thu, 23 Oct 2008 16:37:43 +0000
X-Authority-Analysis: v=1.0 c=1 a=gjHhN06smIIA:10 a=liyGigqBEMQA:10 a=48vgC7mUAAAA:8 a=MVm5Yr9nSXuRcVtt6UQA:9 a=rb5PnB5H7wEtQ_lT8FAA:7 a=WY4JyX0Wo6thwLUmAoeD6VpBtQ8A:4 a=8peU3wBK19oA:10 a=9k6G2--EmesA:10 a=r9vth0PIv-oA:10 a=rn3Q8Ux-5rcA:10 a=e1i35A98MB8A:10 a=78M5ERyKqZAA:10 a=g-J4WiLAdV0A:10 a=h9s5Ru71U4oA:10
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 23 Oct 2008 12:37:41 -0400
To: Edward Lewis <Ed.Lewis@neustar.biz>, namedroppers@ops.ietf.org
From: Michael StJohns <mstjohns@comcast.net>
Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME
Cc: ed.lewis@neustar.biz
In-Reply-To: <a06240802c525f2112a16@[172.16.2.71]>
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> <a06240802c525f2112a16@[172.16.2.71]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
Message-Id: <E1Kt3CK-000MoD-67@psg.com>
At 05:27 AM 10/23/2008, Edward Lewis wrote: >At 20:54 -0400 10/22/08, Michael StJohns wrote: >>After thinking about this topic for a while, I'm still bothered by the >>inconsistency of treatment here. > >What inconsistency? See my note to Ben. >>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. > >This makes as much sense as "matrix management." DNAME isn't a delegation, it's a query restart. What if the DNAME says there is a DS for the target but following the tree down to the target has no DNAME? I'm not sure what you're getting at here. DNAMEs point off tree. So if I have foo.example.com DNAME otherexample.com foo.example.com DS <ds data> foo.example.com NSEC [DNAME, DS] <target> otherexample.com DNSKEY <data pointed to by the DS> otherexample.com <rest of the RRs> DNAME says go look at another zone. DS says here's how you bridge the trust. If you're saying, what happens if you do a DNAME to a name subordinate to the DNAME - isn't that one of those illegal cases for DNAME? >>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. > >This is not a problem. If the target of the DNAME is not DNSSEC protected, it doesn't matter to the DNS. This is a problem. DNAME publisher thought the target was protected, resolver didn't have trust anchors for it. >The application maybe, but what can it do? If the target administrator has not signed the zone, then the application simply cannot validate the answer via DNSSEC. > >>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. > >I think you are expecting too much from DNSSEC. > >Thinking about this scenario, if your application really needed security like this, why would there be the situation of secure DNAME insecure DNAME secure? Although this flip-flop may happen, will it happen where it matters? Is it realistic? Or are we whacking with a sledgehammer at a shadow? I used that one as an example to try and figure out what the output state was and got an answer from all of you that was inconsistent with the general contract. In the case I'm proposing - once you went unsecure - as provide by the DS chain through the DNAME - then you'd stay unsecure, just like you do now with signed delegations into unsigned zones. >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-571-434-5468 >NeuStar > >Never confuse activity with progress. Activity pays more. > >-- >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/> -- 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/>
- [dnsext] Reminder: two WGLC closing in one week Andrew Sullivan
- Re: [dnsext] Reminder: two WGLC closing in one we… Scott Rose
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Edward Lewis
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- DNAME (and CNAME) vs DNSSEC (Was: [dnsext] Remind… Andrew Sullivan
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- [dnsext] Re: DNAME (and CNAME) vs DNSSEC Wes Hardaker
- Re: DNAME (and CNAME) vs DNSSEC (Was: [dnsext] Re… Edward Lewis
- [dnsext] recommeded contents for Re: DNAME (and C… Edward Lewis
- [dnsext] flip-flopping secure and unsecure DNAME/… Edward Lewis
- Re: [dnsext] recommeded contents for Re: DNAME (a… Scott Rose
- [dnsext] Re: DNAME (and CNAME) vs DNSSEC Wes Hardaker
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: [dnsext] flip-flopping secure and unsecure DN… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… John Dickinson
- Re: [dnsext] Reminder: two WGLC closing in one we… Florian Weimer
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Florian Weimer
- Re: [dnsext] Reminder: two WGLC closing in one we… Olafur Gudmundsson
- Re: [dnsext] flip-flopping secure and unsecure DN… Edward Lewis
- the DO bit Re: [dnsext] Reminder: two WGLC closin… Edward Lewis
- Re: the DO bit Re: [dnsext] Reminder: two WGLC cl… bmanning
- Re: the DO bit Re: [dnsext] Reminder: two WGLC cl… David Conrad
- Re: [dnsext] flip-flopping secure and unsecure DN… Ben Laurie
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: [dnsext] flip-flopping secure and unsecure DN… Wouter Wijngaards
- Re: [dnsext] flip-flopping secure and unsecure DN… Ben Laurie
- Re: [dnsext] flip-flopping secure and unsecure DN… Alex Bligh
- Re: [dnsext] flip-flopping secure and unsecure DN… Ben Laurie
- CNAME/DNAME - Re: [dnsext] flip-flopping secure a… Edward Lewis
- Re: [dnsext] flip-flopping secure and unsecure DN… Shane Kerr
- Re: [dnsext] flip-flopping secure and unsecure DN… Alex Bligh
- Interpreting DNSSEC was Re: [dnsext] flip-floppin… Edward Lewis
- Re: [dnsext] flip-flopping secure and unsecure DN… Nicholas Weaver
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Alex Bligh
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: CNAME/DNAME - Re: [dnsext] flip-flopping secu… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: CNAME/DNAME - Re: [dnsext] flip-flopping secu… Edward Lewis
- Re: CNAME/DNAME - Re: [dnsext] flip-flopping secu… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Ben Laurie
- Re: CNAME/DNAME - Re: [dnsext] flip-flopping secu… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Ben Laurie
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Nicholas Weaver
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Mark Andrews
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Wouter Wijngaards
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Ben Laurie
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Mark Andrews
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Stephane Bortzmeyer
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis