Re: [dane] An AD bit discussion

Simo Sorce <simo@redhat.com> Sat, 01 March 2014 18:05 UTC

Return-Path: <simo@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 AE12B1A026A for <dane@ietfa.amsl.com>; Sat, 1 Mar 2014 10:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.55
X-Spam-Level:
X-Spam-Status: No, score=-5.55 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 vC9flUPvY9nz for <dane@ietfa.amsl.com>; Sat, 1 Mar 2014 10:05:13 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id D99491A0262 for <dane@ietf.org>; Sat, 1 Mar 2014 10:05:11 -0800 (PST)
Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s21I58er029012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 1 Mar 2014 13:05:08 -0500
Received: from [10.3.113.6] ([10.3.113.6]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s21I57SL000418; Sat, 1 Mar 2014 13:05:07 -0500
From: Simo Sorce <simo@redhat.com>
To: Michael Richardson <mcr@sandelman.ca>
In-Reply-To: <17001.1393638770@sandelman.ca>
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>
Content-Type: text/plain; charset="UTF-8"
Organization: Red Hat, Inc.
Date: Sat, 01 Mar 2014 13:05:07 -0500
Message-ID: <1393697107.22047.24.camel@willson.li.ssimo.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9s8q5UXavPiQ1gM2rOD0La-dLuc
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 18:05:19 -0000

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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York