Re: [dane] An AD bit discussion

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 02 March 2014 14:05 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 0999C1A0721 for <dane@ietfa.amsl.com>; Sun, 2 Mar 2014 06:05:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.019
X-Spam-Level: *
X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] 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 QMUh5TfoiXHC for <dane@ietfa.amsl.com>; Sun, 2 Mar 2014 06:05:39 -0800 (PST)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 189F91A06D1 for <dane@ietf.org>; Sun, 2 Mar 2014 06:05:39 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 40EBB2002F for <dane@ietf.org>; Sun, 2 Mar 2014 10:24:00 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 85BC1647C9; Sun, 2 Mar 2014 09:05:36 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7629B63AB2 for <dane@ietf.org>; Sun, 2 Mar 2014 09:05:36 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: dane WG list <dane@ietf.org>
In-Reply-To: <1393697107.22047.24.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> <17001.1393638770@sandelman.ca> <1393697107.22047.24.camel@willson.li.ssimo.org>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Sun, 02 Mar 2014 09:05:36 -0500
Message-ID: <25620.1393769136@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6aVXZMubTBe0mqxbTj_uzmQNNRM
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: Sun, 02 Mar 2014 14:05:40 -0000

Simo Sorce <simo@redhat.com>; wrote:
    > On Fri, 2014-02-28 at 20:52 -0500, Michael Richardson wrote:
    >> 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.

    > Yes this is the worry, getting to an unmanageable situation that will
    > discourage people from using DNSSEC.

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

    > Understandable, but I have the impression this is a separate problem.

The only *API* that we presently have is built on top of resolv.conf which
makes use to *DNS*, and that API's only DNSSEC control is *AD*.  So, it's not
as yet, a separate problem.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-