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/>