Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-12.txt

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 03 October 2019 15:29 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6A8120817 for <dnsop@ietfa.amsl.com>; Thu, 3 Oct 2019 08:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5IVC_3F656U4 for <dnsop@ietfa.amsl.com>; Thu, 3 Oct 2019 08:29:20 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B6A120809 for <dnsop@ietf.org>; Thu, 3 Oct 2019 08:29:19 -0700 (PDT)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 563FD2A7B52 for <dnsop@ietf.org>; Thu, 3 Oct 2019 11:29:18 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <alpine.DEB.2.20.1910031202210.11804@grey.csi.cam.ac.uk>
Date: Thu, 3 Oct 2019 11:29:17 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: dnsop@ietf.org
Message-Id: <F1F0138F-C7A4-41BA-8C3E-BDFA29C13B63@dukhovni.org>
References: <156997343802.26389.15326556193059712475@ietfa.amsl.com> <alpine.DEB.2.20.1910021250120.11804@grey.csi.cam.ac.uk> <B640CD6C-863D-44E7-A085-BE44D2D3BCCC@dukhovni.org> <alpine.DEB.2.20.1910031202210.11804@grey.csi.cam.ac.uk>
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Gn6aHrVgjWQLU9y1z0EKt6jHKAo>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-12.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Oct 2019 15:29:23 -0000

> On Oct 3, 2019, at 7:11 AM, Tony Finch <dot@dotat.at> wrote:
> 
>>> [ I'm still not convinced "indeterminate" is a coherent validation state... ]
>> 
>> It happens when glue NS records are available, but DS RRsets are not.
> 
> That is "insecure".

No, by "available" I meant lookup succeeded (returning valid records,
NODATA or NXDOMAIN, with DoE as appropriate).  By "unavailable", I
meant a timeout, ServFail, bogus reply, ...

> I think the definitions of the terms in RFC 4033 are a lot more clear than
> RFC 4035. By the 4033 definitions the distinction between insecure and
> indeterminate is whether you have a covering trust anchor or not, so
> nothing is indeterminate any more for normal validator configurations.

A clear but vacuous/redundant definition is not useful.  In RFC7672 I
chose the 4035 variant, because it is actually useful:

   https://tools.ietf.org/html/rfc7672#section-2.1.1

The RFC4033 definition of "indeterminate" is not usefully different
from "insecure", and as you note, with the root signed, is mostly no
longer applicable.

This state is different from "bogus", "insecure" or "secure". The
resolver has an answer whose security status is unknown (indeterminate),
because the records needed to determine that status could not be
obtained (which is different from "missing").

-- 
	Viktor.