IETF Logo Mail Archive

Re: [dane] An AD bit discussion

Michael Richardson <mcr@sandelman.ca> Sat, 01 March 2014 01:52 UTC

Return-Path: <mcr@sandelman.ca>
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 3D51B1A0404 for <dane@ietfa.amsl.com>; Fri, 28 Feb 2014 17:52:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.59
X-Spam-Level:
X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 KqNPBrGReNIP for <dane@ietfa.amsl.com>; Fri, 28 Feb 2014 17:52:55 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) by ietfa.amsl.com (Postfix) with ESMTP id 5A01F1A03A1 for <dane@ietf.org>; Fri, 28 Feb 2014 17:52:55 -0800 (PST)
Received: from sandelman.ca (CPE001b2128d533-CM185933f8bd5e.cpe.net.cable.rogers.com [99.240.158.182]) by relay.sandelman.ca (Postfix) with ESMTPS id DE8732207A; Fri, 28 Feb 2014 20:52:52 -0500 (EST)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E6BAECA0D7; Fri, 28 Feb 2014 20:52:50 -0500 (EST)
From: Michael Richardson <mcr@sandelman.ca>
To: Simo Sorce <simo@redhat.com>
In-reply-to: <1393617370.22047.22.camel@willson.li.ssimo.org>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca> <912.1393614300@sandelman.ca> <1393617370.22047.22.camel@willson.li.ssimo.org>
Comments: In-reply-to Simo Sorce <simo@redhat.com> message dated "Fri, 28 Feb 2014 14:56:10 -0500."
X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.1
Date: Fri, 28 Feb 2014 20:52:50 -0500
Message-ID: <17001.1393638770@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6Hg4Ge4cprdjX7TuyOO7uU7jnrU
X-Mailman-Approved-At: Sat, 01 Mar 2014 00:42:56 -0800
Cc: dane WG list <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: Sat, 01 Mar 2014 01:52:56 -0000

Simo Sorce <simo@redhat.com> wrote:
    >> For this reason, I think that applications should not set or depend
    >> upon the AD bit, even if the resolver is ::1.  They either understand
    >> DNS(SEC), or they use an API call way more sophisticated than
    >> getaddrinfo() to do their connections.  Java had the right idea, but
    >> the implementation and error reporting was very poor.

    > Nothing in this proposal prevents you from doing that for applications
    > you care about. OTOH forcing applications to a completely new API by
    > refusing this proposal on your grounds will guarantee less applications
    > will use DNSSEC. And DNSEC support will rapidly fragment making
    > system-wide management a lot more difficult. I think that prospect is a
    > much worse evil.

If I understand what you are saying, you are worried that different
applications will make up different DNSSEC APIs, and each application will
have different controls.

I am not opposed to centralized DNSSEC resolution (whether on the same host,
or via a trusted channel).  It's that I am dissastified with "SERVFAIL"
as the only indication of a problem... 

-- 
Michael Richardson
-on the road-

v2.23.0 | Report a Bug | By Email