Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME
Michael StJohns <mstjohns@comcast.net> Thu, 23 October 2008 16:31 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 A251B3A6405; Thu, 23 Oct 2008 09:31:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.478
X-Spam-Level:
X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=-1.040, 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 OLr5P0Cv6Pq7; Thu, 23 Oct 2008 09:31:29 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 53A103A685C; Thu, 23 Oct 2008 09:31:29 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Kt301-000LBZ-QW for namedroppers-data@psg.com; Thu, 23 Oct 2008 16:25:25 +0000
Received: from [76.96.30.40] (helo=QMTA04.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <mstjohns@comcast.net>) id 1Kt2zn-000L9Z-6V for namedroppers@ops.ietf.org; Thu, 23 Oct 2008 16:25:20 +0000
Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id WEhQ1a0040S2fkCA4GR99v; Thu, 23 Oct 2008 16:25:09 +0000
Received: from MIKES-LAPTOM.comcast.net ([68.48.0.197]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id WGR51a00U4F1VyU8VGR63k; Thu, 23 Oct 2008 16:25:08 +0000
X-Authority-Analysis: v=1.0 c=1 a=gjHhN06smIIA:10 a=liyGigqBEMQA:10 a=hqaSkvWfAAAA:8 a=OzSqGtDSAAAA:8 a=tLdN9z_5qzAnzNSLCsAA:9 a=YnxxknQPltqC-fd1IK4A:7 a=pSuRVmeAMV5tSVlzk4JmigoBYOAA:4 a=h9s5Ru71U4oA:10
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 23 Oct 2008 12:25:06 -0400
To: Ben Laurie <ben@links.org>
From: Michael StJohns <mstjohns@comcast.net>
Subject: Re: Interpreting DNSSEC was Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME
Cc: namedroppers@ops.ietf.org
In-Reply-To: <49005921.2090108@links.org>
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> <49005921.2090108@links.org>
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: <E1Kt301-000LBZ-QW@psg.com>
At 06:59 AM 10/23/2008, Ben Laurie wrote: >Michael StJohns wrote: > >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.) Hi Ben - One of the problem we get with DNS is that there are two views of the data (at least) - the publisher's, and the resolver's views. DNSSEC makes this more complicated by the presence or absence of certain trust anchors. As publisher, I have a signed domain, and as publisher, I publish a DNAME also pointing at a signed domain. I've done my due diligence as you suggest - I even own the target zone. As resolver, I get a trust anchor for the first domain (more probably for a parent of the domain), but I don't have any a priori information that the target domain is also signed (or even that I had a redirect to that zone), so I don't know to get a trust anchor for it. There's no way of encoding in DNS/DNSSEC the publishers security intentions with respect to the complete DNAME chain. This leads to the problem where the publisher thought it was delegating into a signed zone, but the resolver thought the zone was unknown (no superior trust anchor). The resolver has no way of telling that the publisher really thought this zone was signed and that the resolver should return a BOGUS answer if the target zone wasn't. Answering Ed's question about inconsistency here: In a resolution without indirect records (e.g. DNAME, CNAME, MX, etc), the resolvers expectation about the security state of the answer are originally set by the presence or absence of a trust anchor and, assuming the trust anchor is present, that expectation changes only upon proof that it should (e.g. signed delegation into unsigned zone). With DNAME, once the resolver starts doing lookups in the target zone, it restarts its expectation of the state of the answer based on what it knows about trust anchors for the target. There is no chain of proof possible from the DNAME zone to the target zone in this model. My suggestions are an attempt to provide a chain of proof from the original trust anchor (provided by the DNAME publisher or its parent) through to the final answer. If that chain of proof validates, the resolver can say something useful about the entire answer chain and the final answer and I think that's the only case in which this is true. The case where the resolver just happens to have trust anchors for the DNAME zone and all of the target zones says useful things about each individual zone lookup, but not about the compound answer (I can elaborate here about DNAME publisher expectations and target zone publisher actions if necessary). >-- >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/>
- [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