Re: [dane] An AD bit discussion

Petr Spacek <pspacek@redhat.com> Tue, 11 March 2014 07:32 UTC

Return-Path: <pspacek@redhat.com>
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 40F1A1A027F for <dane@ietfa.amsl.com>; Tue, 11 Mar 2014 00:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.449
X-Spam-Level:
X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, 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 yDWhnTGhEHBQ for <dane@ietfa.amsl.com>; Tue, 11 Mar 2014 00:32:47 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 669BE1A0278 for <dane@ietf.org>; Tue, 11 Mar 2014 00:32:47 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2B7Wbpm015013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <dane@ietf.org>; Tue, 11 Mar 2014 03:32:37 -0400
Received: from pspacek.brq.redhat.com (vpn1-7-23.ams2.redhat.com [10.36.7.23]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2B7WZbq001296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <dane@ietf.org>; Tue, 11 Mar 2014 03:32:37 -0400
Message-ID: <531EBC13.1060007@redhat.com>
Date: Tue, 11 Mar 2014 08:32:35 +0100
From: Petr Spacek <pspacek@redhat.com>
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dane@ietf.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>
In-Reply-To: <20140311064639.C613F10E0717@rock.dv.isc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/B6PGvjXgF5i9oDJ3bf3-W78-E2o
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 07:32:49 -0000

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.

I'm curious if this conflicts with AD bit definition in RFCs or not.

-- 
Petr^2 Spacek