Re: [dnsext] Reminder: two WGLC closing in one week
Michael StJohns <mstjohns@comcast.net> Tue, 23 September 2008 01:35 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 AE0E23A685D; Mon, 22 Sep 2008 18:35:54 -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_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 5XAOJ53p8iGa; Mon, 22 Sep 2008 18:35:53 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D6D373A6855; Mon, 22 Sep 2008 18:35:46 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Khwdp-000J3V-QJ for namedroppers-data@psg.com; Tue, 23 Sep 2008 01:24:37 +0000
Received: from [76.96.62.64] (helo=QMTA07.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <mstjohns@comcast.net>) id 1Khwdk-000J2t-9E for namedroppers@ops.ietf.org; Tue, 23 Sep 2008 01:24:35 +0000
Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Hnia1a00D0QuhwU571QXbp; Tue, 23 Sep 2008 01:24:31 +0000
Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA02.westchester.pa.mail.comcast.net with comcast id J1Q01a00F2P9w053N1Q03F; Tue, 23 Sep 2008 01:24:00 +0000
X-Authority-Analysis: v=1.0 c=1 a=gwu2n-TYGH0A:10 a=YzQq6kKhkNwA:10 a=A1X0JdhQAAAA:8 a=yHGabWYmAAAA:8 a=iFNjgg71AAAA:8 a=bCom7euS9m01ql-lI64A:9 a=8S57BEGkTXZ5Mj6q9R0A:7 a=r3XL3-0jIEqnQ7XpBjukXE7EAtoA:4 a=a9rVEY26BewA:10 a=g-J4WiLAdV0A:10 a=PKgchsl1YdkA:10 a=iw4bf7yTzGQA:10 a=I2EqgwFF2xUA:10
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 22 Sep 2008 21:24:29 -0400
To: Mark Andrews <Mark_Andrews@isc.org>
From: Michael StJohns <mstjohns@comcast.net>
Subject: Re: [dnsext] Reminder: two WGLC closing in one week
Cc: Andrew Sullivan <ajs@commandprompt.com>, namedroppers@ops.ietf.org
In-Reply-To: <200809230016.m8N0GS9E069236@drugs.dv.isc.org>
References: <Your message of "Mon, 22 Sep 2008 15:12:44 -0400." <E1KhqqB-000CE1-QD@psg.com> <200809230016.m8N0GS9E069236@drugs.dv.isc.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: <E1Khwdp-000J3V-QJ@psg.com>
I started to write a longish response, but got to a point where I think I have a question that sort of explains where I'm coming from. For Mark's message asking how this differs from CNAME - there are basically two types of CNAME - those with targets under the original trust anchor and those that aren't. The former have no real cascade implications as long as the final target and all of the intermediates are under the same trust anchor. The latter type are most like DNAME, I haven't seen any security analysis of a CNAME cascade. I may have missed it over the years - if so I apologize for my ignorance. In the most complex lookup case, we've got cascades of CNAME and DNAME lookups - each being treated in isolation from each other for security purposes. Is this a correct treatment? Or just the treatment that's possible given the current definitions? For example, we start a query in a secure zone - it validates; but DNAMEs into an unsecure zone; and bounces (CNAMEs) back into a secure zone which also validates. Is the "result" secure, unsecure or some other state? Original query is: "www.somewhere.example.com A" and we have a trust anchor for somewhere.example.com At somewhere.example.com is a DNAME into unsecure.com which is not signed or for which we have no trust anchor. At www.unsecure.com is a CNAME pointing at www.otherexample.com We have a trust anchor for otherexample.com and the zone contents will verify. At www.otherexample.com is a A record - the answer to our original query. It turns out the original data at www.unsecure.com was an A record... a hacker got in and changed it. Does the result parse out as verified? Should it? Given that once a validator wanders in to an insecure zone, it can be steered where ever, should we ever mark that data as "trusted validated"? Sure the last question validated, but the fact that it did is probably worthless for determining the security of the query response. At 08:16 PM 9/22/2008, Mark Andrews wrote: >In message <E1KhqqB-000CE1-QD@psg.com>, Michael StJohns writes: >> Hi Andrew - >> >> At Scott's request I took a look at the dname document. Keep in mind that I'm >> looking at it pretty much for the first time. Unfortunately, I don't think its >> ready for prime-time. Most of the document is fine - but the section on DNSSE >> C is woefully lacking. >> >> DNSSEC unfortunately makes things more difficult. Having DNAMEs plus DNSSEC st >> retches the complications almost to the breaking. > > How? > >> The section needs more than a 1 page description of why DNSSEC servers need to >> understand DNAME, it needs a discussion of the various combinations of modes in >> which a resolver can find itself when following a DNAME chain. > > Why? DNAME is a method to synthesis a CNAME. Once you have the > CNAME you give it the *same* trust level that you gave the DNAME > and proceed as if there was just a CNAME there. > >> For example - what happens if the DNAME is signed, but the referenced target is >> n't? > > What happens if a CNAME validates and the name it points to doesn't? > >> What happens if both are signed, but the resolver doesn't have a trust an >> chor for the target but has one for the DNAME? For the DNAME but not the target > > What happens if a CNAME is signed an it's target is signed but you > don't have a trust anchor for the target? > >> ? What happens if the DNAME is directly reachable (e.g. querier is a validatin >> g recursive resolver) but the target is available only through a forwarder? > > What happens is the CNAME is directly reachable but the target is > available only through a forwarder? > >> What happens if the DNAME and the target are signed with different algorithm >> and the querier only understands one of they. > > What happens if the CNAME and the target are signed with different > algorithm and the querier only understands one of they? > >> I can see about a number of different ways to have different resolvers behave >> given different combinations. I think they need to be called out and a specifi >> c behavior proposed for each prior to sending this forward. > > Why. The answers to DNAME are really no different to how you handle > the CNAME. > > The only thing really different about DNAME is to handle YXDOMAIN. > > Mark > >> One proposal, once the "must be signed bit" is set (e.g. DNAME or target subord >> inate to a trust anchor without a delegation to unsecure), then ALL data must b >> e signed to be considered valid. (Not sure this is the right way of doing thin >> gs, but its a conversation starter). >> >> Sorry - Mike >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- 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