Re: [dane] An AD bit discussion

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 28 February 2014 19: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 4188E1A01EF for <dane@ietfa.amsl.com>; Fri, 28 Feb 2014 11:05:08 -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 ChLth6iUK7GA for <dane@ietfa.amsl.com>; Fri, 28 Feb 2014 11:05:05 -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 D0F771A016C for <dane@ietf.org>; Fri, 28 Feb 2014 11:05:04 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F6B02002C for <dane@ietf.org>; Fri, 28 Feb 2014 15:23:20 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 0863F647C9; Fri, 28 Feb 2014 14:05:00 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E142463AB2 for <dane@ietf.org>; Fri, 28 Feb 2014 14:05:00 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: dane WG list <dane@ietf.org>
In-Reply-To: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>
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: Fri, 28 Feb 2014 14:05:00 -0500
Message-ID: <912.1393614300@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/HCu1FeI-evKnr8N0Cf8okVZIbjc
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: Fri, 28 Feb 2014 19:05:08 -0000

Paul Wouters <paul@nohats.ca>; wrote:
    > 1 Applications can either do dnssec validation themselves, or trust the
    > AD bit.

    > 2 It is undesirable that each application has its own DNSSEC validation
    > code, trust anchors and DNS cache.

    > 3 It is undesirable that applications blindly trust the AD bit when
    > resolv.conf points to another host as the AD bit could have been modified
    > on the network.

    > 4 In the ideal world tomorrow, each host has its own automatically
    > configured, perfectly working validing DNS server and resolv.conf can
    > be ignored or is always hardcoded with nameserver 127.0.0.1

My problem isn't that the AD is insecure, but that it isn't very useful.
Going back 10 years to the various DNSSEC workshops, one of the things that I
wanted was more information about why there was a validation failure.

For instance, if I have previously contacted example.com, and I have
it's A/AAAA or more interestingly, the DANE borne public key for the service
I want to reach cached, or leap-of-faith'ed, I don't care as much if the
DNSSEC fails to validate because a signature expired.

If it fails to validate because the data is correct, I expect the bad data to
be discarded, and for it to try again.  At some point (<<5s) the application
needs to get some kind of report that name is not presently available.
(Happy eyeballs, or some other mechanism might want to try something else)

This is doubly true if I have contact with the user who
can I can:
    a) advise of the specific reason for the failure
       (which up to now, would be followed by facepalm and one of geeks
       goes to fix the problem....)

    b) find out what they want to do now.

SERVFAIL / "Host now found" is simply not acceptable information.

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.

--
]               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 =-