IETF Logo Mail Archive

Re: [dnsext] Issues in WGLC of dnssec-bis-updates

"W.C.A. Wijngaards" <wouter@nlnetlabs.nl> Tue, 07 February 2012 16:54 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 CBE7E21F884E; Tue, 7 Feb 2012 08:54:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328633646; bh=EOuQmNHw9PfwWTFfqOF484RzELnlS6oXbhnNUSdN0z8=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ls4Ka+x75sDZOOod3aDRCZhUqrSj5dHBUT0L/Nt2XdBGHEFuMixQV88OFWE0PJuWJ aFyybqUADE1dbFZ/7HmtQy2ra8FGJfPlsIuPIMtWX+VVBIyKAdQLyGUGgiIFwn+T6q eJtQeyqNmSEECOn/kR8tLJc0IAedzgQgvfLvksOw=
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 75C7121F8855 for <dnsext@ietfa.amsl.com>; Tue, 7 Feb 2012 08:54:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.778
X-Spam-Level:
X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1]
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 lvt13lic6Gvq for <dnsext@ietfa.amsl.com>; Tue, 7 Feb 2012 08:54:04 -0800 (PST)
Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by ietfa.amsl.com (Postfix) with ESMTP id A871021F884E for <dnsext@ietf.org>; Tue, 7 Feb 2012 08:54:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id BA2AF58B80 for <dnsext@ietf.org>; Tue, 7 Feb 2012 17:54:03 +0100 (CET)
Received: from [192.168.254.3] (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id C593558498 for <dnsext@ietf.org>; Tue, 7 Feb 2012 17:53:58 +0100 (CET)
Message-ID: <4F315725.4010705@nlnetlabs.nl>
Date: Tue, 07 Feb 2012 17:53:57 +0100
From: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16
MIME-Version: 1.0
To: dnsext@ietf.org
References: <20120207151820.GE9478@crankycanuck.ca> <4F31449C.9040604@nlnetlabs.nl> <20120207162344.GH9478@mail.yitter.info>
In-Reply-To: <20120207162344.GH9478@mail.yitter.info>
X-Enigmail-Version: 1.1.2
X-Virus-Scanned: clamav-milter 0.97.3 at rotring
X-Virus-Status: Clean
Subject: Re: [dnsext] Issues in WGLC of dnssec-bis-updates
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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andrew,

On 02/07/2012 05:23 PM, Andrew Sullivan wrote:
> On Tue, Feb 07, 2012 at 04:34:52PM +0100, W.C.A. Wijngaards wrote:
>>
>> I feel the first (4033) is a better description.  I personally use a
>> definition for this as: this portion of the tree does not have a trust
>> anchor above it (higher up the hierarchy), and therefore is not secure,
>> insecure, or bogus.  Note that with the root trust anchor the
>> indeterminate state no longer occurs, since we know everything is
>> covered by that trust anchor.
> 
> This is extremely interesting and helpful; thanks.  I wonder about
> something, though.  What should we call the state you get when you
> have a validating resolver that can only speak to upstream resolvers
> that all respond NOTIMP (or similar) to the DO bit?  That case appears
> to be covered by the 4035 definition and not the 4033 one.  Is this
> "unvalidatable" rather than "indeterminate"?

This would make data that is not covered by a trust anchor indeterminate
(like it was before, you have no anchor that covers it so can check no
signatures).  Data covered by a trust anchor becomes bogus, because you
cannot get the DNSSEC data for zone of the trust anchor, and its
delegations need to tell you if the data covered by it is secure or
insecure; these signatures are withheld, and this makes the result bogus.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPMVckAAoJEJ9vHC1+BF+NRoYP/A+wlagWZORkKRV6MsSc7gwh
yKxg7uRRDizkiVyA9cvpW8HeRAWIhPpZIseraUWG1aAM6pnuUuwHOWvpHtPvvg8S
Jtf2EvYx+mUxgnoloxplTAJsDzoWNcIv1CVaQbxXl3FAdJ1HcT10ETduRXBhE6KI
11yyv+knqsFL4bv2yiNXUrumH41J7VYYC2LYTTexohMO3+kXPbCybR0hKE+7+P1T
rbwbpBPTwPCaILTaLzAKML3LAM3f+DfvNTX+WFpAehhVvjOVndtkgcBw6n/2LzVu
qP3YyB4N0Hwp/o94hlcsRbnitCfcQ7EGUkd9+knc1ZMMOWBaIABtYagN+fcspKNI
oIYKjBAkJoCBMFh9oveCQ3qiGYdtqHsaKaF/I15AZ6Zz0+S2zXoRlTQulxo2oclx
jsu5CZDMC7SuyYYkHPjndbDFTZgt0Mgi7n+peQGMoy2DeWI+7HEta0nizUVJwofT
QJI8Wx9WaI4Q+n+exm2EhwD6e6vFX+zytEbaFpTq0NABYlAq87IclGwcG4scgqaL
XwwNN8F/2z8ia194uGF5k57orqYOsA5qYlx/XDmpSK8zZuOYX+/7td//oj0Z5aY2
z7mV5+3E59uI/wspMcMNChrD6bKsYqwx51TD/mODspa8t2mOTbvbmO6TCIXtofnh
8mQerDa0DoV3MNbHI/LO
=VZI5
-----END PGP SIGNATURE-----
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

v2.23.0 | Report a Bug | By Email