Re: [dnsext] Reminder: two WGLC closing in one week

Michael StJohns <mstjohns@comcast.net> Tue, 23 September 2008 04:47 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 5F6AF3A6AC8; Mon, 22 Sep 2008 21:47:28 -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 awTThl1HNypG; Mon, 22 Sep 2008 21:47:21 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC6D83A68AB; Mon, 22 Sep 2008 21:47:20 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Khzea-000Bob-2Y for namedroppers-data@psg.com; Tue, 23 Sep 2008 04:37:36 +0000
Received: from [76.96.62.40] (helo=QMTA04.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <mstjohns@comcast.net>) id 1KhzeO-000BnV-G0 for namedroppers@ops.ietf.org; Tue, 23 Sep 2008 04:37:33 +0000
Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA04.westchester.pa.mail.comcast.net with comcast id J1cD1a03o0QuhwU544dPPa; Tue, 23 Sep 2008 04:37:23 +0000
Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA02.westchester.pa.mail.comcast.net with comcast id J4cs1a0092P9w053N4csAF; Tue, 23 Sep 2008 04:36:53 +0000
X-Authority-Analysis: v=1.0 c=1 a=gwu2n-TYGH0A:10 a=YzQq6kKhkNwA:10 a=-00ntuNjTI1CNvlMxtcA:9 a=Cg-jgozk8NH_k2Xc4WsA:7 a=MYp2CI7HHL03vZpmsQi2QIra4AIA:4 a=lv1_I0N3rasA:10 a=h9s5Ru71U4oA:10
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 23 Sep 2008 00:37:21 -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: <200809230309.m8N39Uwt073117@drugs.dv.isc.org>
References: <Your message of "Mon, 22 Sep 2008 22:52:10 -0400." <20080923025212.A378411402C@mx.isc.org> <200809230309.m8N39Uwt073117@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: <E1Khzea-000Bob-2Y@psg.com>

At 11:09 PM 9/22/2008, Mark Andrews wrote:

>In message <20080923025212.A378411402C@mx.isc.org>, Michael StJohns writes:
>> OK - so if the last chain validates, but the intermediate chain was unsecure, t
>> hen you return the answer, but don't set the AD bit.  If the last chain doesn't
>>  validate, you return what?  The data without the AD bit, or  RCODE 2/SERVFAIL?
>
>        SERVFAIL.  If they ask with cd=1 then they get the full answer.
>
>>   (I.e.is it really possible to have data that's both bogus and unsecure?)
>
>        A particulare RRset is falls into exactly one of secure, insecure or
>        bogus post validation.

Right, but the answer is a mixture of three RRSets - one secure, one unknown and one bogus... which I guess makes the whole thing bogus and results in the return of RCODE 2.


>> Is t
>> here any reason to do validation for the third chain in my example once you've 
>> wandered over into unsecure land?  
>
>        Yes as you may be asked the later question.

Fair enough.


>> Where - exactly - in the documentation of either CNAME or DNAME (or DNSSEC for 
>> that matter) is your last conclusion stated as a specific protocol element?  I 
>> just back and review 4035 sections 3.1.6, 3.2.3 and 5 and they don't seem to sa
>> y this.  The definition for "secure" in 4.3 only says to trace from the answer 
>> to a trust anchor.  The definition for insecure *could* be read to say what you
>> said, but then it would be in conflict with the definition for "secure".
>
>   A security-aware name server MUST NOT set the AD bit in a response
>   unless the name server considers all RRsets in the Answer and
>   Authority sections of the response to be authentic.  

OK. I can go along with this reading - but I think I'm still not quite done.


So the last question is what goes on when you have the same three queries - except the last one now validates, and the DO bit wasn't set from the stub resolver? (e.g, I won't understand the lack of AD bit)

The simple answer would be to return the three RRSets - but is that the right approach or only one of several correct approaches?  

I could argue the paranoids point, that once the answer becomes secure, unless it becomes securely unsecure (by proving there's no DS at a delegation point), then the final answer must either be secure or bogus.  In other words, if I get a referral via a CNAME or DNAME into unsecure space, then the final answer should be "bogus".

The above is different than the secure delegation to an unsecure zone:  The signed delegation to an unsigned zone is controllable by the delegator.  The signed CNAME or DNAME referral to an zone carries no information about whether the referrer/signer believes the target zone/name should be signed.  

I'm trying to reconcile this with the general policies on how data is returned from a validating recursive resolver to a non-DNSSEC aware stub resolver.  The VRR returns an RCODE 2 for any data below a trust anchor it can't validate (bogus), and returns the data which has no superior trust anchor (unknown), returns the data it was able to validate (secure), and returns the data which was below an unsecure delegation point (unsecure). 

I'm not sure I can argue that a DNAME or CNAME into an unknown/unsecure zone from a secure zone is equivalent to an unsecure delegation from that secure zone to a subsidiary, because the target of the DNAME/CNAME can change the DNSSEC status at any time after the CNAME/DNAME is published.  Unfortunately, I can't see any way of encoding the DNAME/CNAME signers expectation of security for the target zone in the current definitions.

So if I follow the principal of "if it started out secure and I can't prove it was meant to be unsecure then it should be bogus if I can't validate it" which we follow for on-tree delegations, shouldn't I follow it for off-tree delegations?

Mike




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