Re: [dane] DNS errors text
Andrew Sullivan <ajs@anvilwalrusden.com> Thu, 02 October 2014 03:39 UTC
Return-Path: <ajs@anvilwalrusden.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 E95CD1A0055 for <dane@ietfa.amsl.com>; Wed, 1 Oct 2014 20:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.758
X-Spam-Level: *
X-Spam-Status: No, score=1.758 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 yuHGyNSprqIk for <dane@ietfa.amsl.com>; Wed, 1 Oct 2014 20:39:56 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982811A004E for <dane@ietf.org>; Wed, 1 Oct 2014 20:39:56 -0700 (PDT)
Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 809378A035 for <dane@ietf.org>; Thu, 2 Oct 2014 03:39:54 +0000 (UTC)
Date: Wed, 01 Oct 2014 23:39:49 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dane@ietf.org
Message-ID: <20141002033948.GB14726@mx1.yitter.info>
References: <542CB20B.4020803@andyet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <542CB20B.4020803@andyet.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6v6x8zmSL7MK8HYsSQCiYd4CRr0
Subject: Re: [dane] DNS errors text
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: Thu, 02 Oct 2014 03:39:58 -0000
On Wed, Oct 01, 2014 at 08:01:47PM -0600, Peter Saint-Andre - &yet wrote: > Section 2.1 of draft-ietf-dane-smtp-with-dane has some thorough text on DNS > errors. Well, yes, but once again I've been caught asleep at the wheel. I know I participated in early work on some of the text below, but apparently threads got away from me that I should have attended to. I object pretty strongly to this: To avoid much repetition in the text below, we will pause to explain the handling of "bogus" or "indeterminate" DNSSEC query responses. These are not necessarily the result of a malicious actor; they can, for example, occur when network packets are corrupted or lost in transit. Therefore, "bogus" or "indeterminate" replies are equated in this memo with lookup failure. While I agree that neither bogus nor interdeterminate responses are necessarily the result of a malicious actor, I am not sure why this should be "equated with" lookup failure. (I'm even more dubious that they're the result of corrupted or lost network packets -- that sounds to me rather more like something that would be handled by the regular DNS mechanisms for this sort of thing, including DNS retries with a smaller EDNS buffer size or reversion to TCP. But never mind that). I'm ok if the idea is just to say this: For the purposes contemplated by this memo, neither bogus nor indeterminate answers are acceptable. Therefore, this memo uses ah analagous strategy to that used by DNSSEC when a validating iterative resolver responds to a stub: SERVFAIL when positive validation fails. The difference in the present case lies in treating bogus and indeterminate as the same thing -- what might be called a 'strongly valid' bias. This is required in order to derive further security properties from the answer received from DNS." There are some other DNS errors in the same section: When a DNSSEC response with a validation status that is either "secure" or "insecure" reports either no records of the requested type or non-existence of the query domain, the response is not a DNS error condition. This is strictly false. The "no records of the requested type" is what is called a NODATA response, and is defined in RFC 2308. It's not an RCODE. But a response of "non-exstence of the query domain" is, if I understand it, an RCODE==3 ("Name Error" or "NXDOMAIN") response, which is certainly an "error" condition in pure DNS terms. For practical purposes in an application, it is quite possibly true that "NODATA" and "NXDOMAIN" -- presuming that they're both provably secure responses, or that you've decided to accept an opt-out proof -- are the same thing. But we don't need to mischaracterise how DNSSEC works in this text (whatever draft it lands in). This isn't exactly true either: Security-aware stub resolvers will, of course, also signal DNS lookup errors in other cases, for example when processing a "ServFail" RCODE, which will not have an associated DNSSEC status. A stub that gets a SERVFAIL, but that is itself validating, is in a perfectly good position to retry with CD=1. If it gets an answer at that point, and yet cannot validate itself, then that is in fact a DNSSEC status: bogus. Otherwise, it's SERVFAIL, which could mean anything. This is underdetermined, but not completely indeterminate. I suggest reading RFC 6840, especially the bits in appendices B and C. Olafur and I both had several painful discussions (independently and together) about that document, and it'd be useful to understand how the interaction of stubs, CD, TA preferences, and failed upstream validation could be made clearer. Instead of A lookup error is thus a failure to obtain the relevant RRset if it exists, or to determine that no such RRset exists when it does not. I suggest For the purposes of this memo, a "lookup error" is either a failure to obtain securely the relevant RRset (if that RRset exists), or to determine securely that no such RRset exists (if it does not). This is a broader meaning than is sometimes used for "lookup error". If you wanted to make the definition cleaner, you could define "secure lookup error" instead. Or something like that. This might help, because sometimes "lookup failure" and "lookup error" seem to be treated the same, and sometimes we have "DNS lookup failure", which appears to be different but I bet actually isn't. I hope this helps rather than hinders. A -- Andrew Sullivan ajs@anvilwalrusden.com
- [dane] DNS errors text Peter Saint-Andre - &yet
- Re: [dane] DNS errors text Paul Hoffman
- Re: [dane] DNS errors text Viktor Dukhovni
- Re: [dane] DNS errors text Andrew Sullivan
- Re: [dane] DNS errors text Viktor Dukhovni
- Re: [dane] DNS errors text Peter Saint-Andre - &yet