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 =-
- Re: [dane] An AD bit discussion Paul Wouters
- [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Ondřej Surý
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Olafur Gudmundsson
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Wiley, Glen
- Re: [dane] An AD bit discussion James Cloos
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Andreas Schulze
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion (correction) Petr Spacek
- Re: [dane] An AD bit discussion (+concerns from g… Petr Spacek
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- Re: [dane] An AD bit discussion (+concerns from g… Viktor Dukhovni
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- [dane] Proposal: AD bit handling in stub-resolver… Petr Spacek
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Simo Sorce
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Simo Sorce
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] Proposal: AD bit handling in stub-reso… Viktor Dukhovni
- Re: [dane] An AD bit discussion Florian Weimer
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Petr Spacek