Re: [dane] An AD bit discussion

Mark Andrews <marka@isc.org> Tue, 11 March 2014 08:09 UTC

Return-Path: <marka@isc.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293A61A03F2 for <dane@ietfa.amsl.com>; Tue, 11 Mar 2014 01:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.448
X-Spam-Level:
X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
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 fvgJLhZqICsl for <dane@ietfa.amsl.com>; Tue, 11 Mar 2014 01:09:09 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9889C1A03E0 for <dane@ietf.org>; Tue, 11 Mar 2014 01:09:08 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 819172383DF; Tue, 11 Mar 2014 08:08:51 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E99AE16005D; Tue, 11 Mar 2014 08:09:50 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id B4F94160055; Tue, 11 Mar 2014 08:09:50 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2AF5B10E2EE8; Tue, 11 Mar 2014 19:09:01 +1100 (EST)
To: Petr Spacek <pspacek@redhat.com>
From: Mark Andrews <marka@isc.org>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca> <20140226155752.GT21390@mournblade.imrryr.org> <alpine.LFD.2.10.1402261114460.3528@bofh.nohats.ca> <87a9d0ei30.fsf@mid.deneb.enyo.de> <20140311064639.C613F10E0717@rock.dv.isc.org> <531EBC13.1060007@redhat.com>
In-reply-to: Your message of "Tue, 11 Mar 2014 08:32:35 +0100." <531EBC13.1060007@redhat.com>
Date: Tue, 11 Mar 2014 19:09:01 +1100
Message-Id: <20140311080901.2AF5B10E2EE8@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/y1UcwtQ6WriNnYrPPFXKpbPI7Pc
Cc: dane@ietf.org
Subject: Re: [dane] An AD bit discussion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Mar 2014 08:09:11 -0000

In message <531EBC13.1060007@redhat.com>, Petr Spacek writes:
> On 11.3.2014 07:46, Mark Andrews wrote:
> >
> > In message <87a9d0ei30.fsf@mid.deneb.enyo.de>, Florian Weimer writes:
> >> * Paul Wouters:
> >>
> >>> Sorry, I mistook the flags in the struct to be the DNS flags. Let me
> >>> rephrase it as "a DNS API call that returns the presence or lack of
> >>> AD bit"
> >>
> >> I think this focus on the AD bit is a grave mistake.  There are other
> >> technologies for securing DNS data.  At least one of them (installing
> >> an authenticated copy of the zone in the resolver) is superior to
> >> DNSSEC according to various criteria, but full implementation requires
> >> that the resolver clears the AD bit.
> >
> > You can set AD=1 with a local copy of the zone.  I actually run
> > named locally like this with full dnssec validation of results
> > returned from the local zone.  You can also just assert AD=1 without
> > doing validation if that is what your local policy states on secure
> > transfer.
> 
> Maybe it is not a problem but I have to ask:
> 
> What if DS records in parent zone are somehow broken? Validating resolvers 
> will see the child zone as bogus but authoritative server for such zone will 
> happily set AD=1.

Yes.
 
> I'm curious if this conflicts with AD bit definition in RFCs or not.
 
It is permitted.

> -- 
> Petr^2 Spacek
> 
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org