[dnsext] What is indeterminate

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 07 February 2012 18:09 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E66221F86B1; Tue, 7 Feb 2012 10:09:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328638143; bh=aO1FsIqBfqUdykmR6bW0bC+c2VQWB2Vz1V2+Jk7V4NA=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=EzKnpYnxUAvT0QxrAuNQu/8sCmTzx4ufeELz8MMPhBxhGsclP8U70VAMuW2VMdBaK nJxJowodJ/Mz10ixkLHEkkh5GnY7NZP22B8NBiJx6UsedcuzsIJRrqHHnwYiVv3YVD EVKNA4qDQHIX8G5OFttIMbiABBv/CEmwN+b5tOHs=
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E4521F8694 for <dnsext@ietfa.amsl.com>; Tue, 7 Feb 2012 10:09:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTt+HDLRpEwq for <dnsext@ietfa.amsl.com>; Tue, 7 Feb 2012 10:09:01 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 97A1D21F8616 for <dnsext@ietf.org>; Tue, 7 Feb 2012 10:08:58 -0800 (PST)
Received: from [10.224.138.41] (m180f36d0.tmodns.net [208.54.15.24]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q17I8thX083719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <dnsext@ietf.org>; Tue, 7 Feb 2012 11:08:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <20120207151820.GE9478@crankycanuck.ca>
Date: Tue, 07 Feb 2012 13:08:56 -0500
Message-Id: <E59CC699-741A-4815-B4CD-D0781420072E@vpnc.org>
References: <20120207151820.GE9478@crankycanuck.ca>
To: DNSEXT Working Group <dnsext@ietf.org>
X-Mailer: Apple Mail (2.1251.1)
Subject: [dnsext] What is indeterminate
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

On Feb 7, 2012, at 10:18 AM, Andrew Sullivan wrote:

> ISSUE 1: Indeterminacy of Indeterminate
> 
> In http://www.ietf.org/mail-archive/web/dnsext/current/msg12176.html,
> Mohan Parthasarathy argues that RFC 4033 and RFC 4035 have
> inconsistent definitions of "Indeterminate".  RFC 4033 says this is
> what Indeterminate means, in section 5:
> 
>   Indeterminate: There is no trust anchor that would indicate that a
>      specific portion of the tree is secure.  This is the default
>      operation mode.
> 
> RFC 4035 has this definition in section 4.3: 
> 
>   Indeterminate: An RRset for which the resolver is not able to
>      determine whether the RRset should be signed, as the resolver is
>      not able to obtain the necessary DNSSEC RRs.  This can occur when
>      the security-aware resolver is not able to contact security-aware
>      name servers for the relevant zones.
> 
> These two do seem to be inconsistent.  In particular, the latter
> apparently can happen when a security-aware resolver with an
> appropriate trust anchor can't find an upstream that can handle the DO
> bit.  Does anyone have an opinion on what to do about this?  We will
> need to come to some very strong agreement quickly, or it will not be
> addressed in this document.
> 
>    DEFAULT ACTION: none.  Without proposed text that finds strong
>    support, this issue will be left out of the document.  

A request to the folks who have done DNSSEC much longer than I have: please do resolve this somehow. It affected the development of DANE, and will probably nail others later.

--Paul Hoffman

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext