IETF Logo Mail Archive

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD

Mark Andrews <marka@isc.org> Tue, 03 April 2018 07:38 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2970124205 for <dnsop@ietfa.amsl.com>; Tue, 3 Apr 2018 00:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-Rs8Uwtpkh3 for <dnsop@ietfa.amsl.com>; Tue, 3 Apr 2018 00:38:53 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ABC5127AD4 for <dnsop@ietf.org>; Tue, 3 Apr 2018 00:38:50 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 0FCE03AB03B; Tue, 3 Apr 2018 07:38:50 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E9FBF160054; Tue, 3 Apr 2018 07:38:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CEC8D16007A; Tue, 3 Apr 2018 07:38:19 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id grIUUws2ZPW1; Tue, 3 Apr 2018 07:38:19 +0000 (UTC)
Received: from [172.25.20.34] (unknown [103.235.108.1]) by zmx1.isc.org (Postfix) with ESMTPSA id 8A59B160054; Tue, 3 Apr 2018 07:38:19 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Mark Andrews <marka@isc.org>
X-Mailer: iPhone Mail (15D100)
In-Reply-To: <64816369-700A-4413-B1F0-160FB145EE6C@gmail.com>
Date: Tue, 03 Apr 2018 17:38:15 +1000
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF3E4F4D-027C-4A2B-8026-14AF3FBA4603@isc.org>
References: <039408B0-89EE-4038-B9C9-CBCC35EC24EC@isc.org> <64816369-700A-4413-B1F0-160FB145EE6C@gmail.com>
To: Geoff Huston <gih902@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pSP2sLhXjWZicat5EidOABBAEbU>
Subject: Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2018 07:38:56 -0000

AD is only set or potentially set in the response if DO or AD is set on the query.

The condition boils down to testing for AD or DO in the query because the answer needs to be secure and there can’t be a CNAME or DNAME pointing to it.  About the only way it to not have a AD would be for there to be a CNAME and the target be insecure based on the other conditions.

I would just remove the condition. 

-- 
Mark Andrews

> On 3 Apr 2018, at 16:39, Geoff Huston <gih902@gmail.com> wrote:
> 
> 
> 
>> On 3 Apr 2018, at 1:10 pm, Mark Andrews <marka@isc.org> wrote:
>> 
>> Do we really want to test for AD?  How many stub resolvers set DO or AD to elicit a AD response?
>> 
> 
> I’m not sure that we are on the same page here. The precondition is: "The AD bit is to be set in the response”  i.e. it is not a test on the query per se - it is a test on the response. Your comment appears to suggest that you believe that the text is asking for a test on the query. That is definitely not the intention of the text. i.e. it does not attempt to say what combination of flags in the query is used to signal that validation is to be applied (thats the role of RFC4035 and RFC6840), but the text is attempting to say “if the resolver has validated the response and is passing back a response that it is marking as being valid” then perform <actions>
> 
> I felt that saying that:
> 
>   o  The DNS response is DNSSEC validated
> 
>   o  the result of validation is "Secure"
> 
>   o  the AD bit is to be set in the response
> 
> would encompass this state. 
> 
> Is there a better way of saying this? Please suggest text if you believe that this could be stated more accurately.
> 
> thanks,
> 
>   Geoff
> 
> 
>

v2.23.0 | Report a Bug | By Email