Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME

Wouter Wijngaards <wouter@NLnetLabs.nl> Mon, 13 October 2008 12:23 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448623A6BA1; Mon, 13 Oct 2008 05:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKMqJnVjt1nd; Mon, 13 Oct 2008 05:23:07 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 492AE3A6B9D; Mon, 13 Oct 2008 05:23:07 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KpMMI-000M5K-54 for namedroppers-data@psg.com; Mon, 13 Oct 2008 12:17:10 +0000
Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <wouter@nlnetlabs.nl>) id 1KpMMA-000M4U-Rh for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 12:17:05 +0000
Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id m9DCGq03077323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 14:16:53 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl)
Message-ID: <48F33C34.3010901@nlnetlabs.nl>
Date: Mon, 13 Oct 2008 14:16:52 +0200
From: Wouter Wijngaards <wouter@NLnetLabs.nl>
User-Agent: Thunderbird 2.0.0.16 (X11/20080723)
MIME-Version: 1.0
To: Michael StJohns <mstjohns@comcast.net>
CC: Ben Laurie <ben@links.org>, Edward Lewis <Ed.Lewis@neustar.biz>, namedroppers@ops.ietf.org
Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME
References: <Your message of "Mon, 22 Sep 2008 15:12:44 -0400." <E1KhqqB-000CE1-QD@psg.com> <200809230016.m8N0GS9E069236@drugs.dv.isc.org> <E1Khwdp-000J3V-QJ@psg.com> <a06240804c4ffc42abc16@[10.122.105.108]> <E1KicTm-000ANO-PO@psg.com> <a06240800c50fd3decd5b@[192.168.1.101]> <48F2DE42.1060209@links.org> <E1KpLkt-000HQ3-Is@psg.com>
In-Reply-To: <E1KpLkt-000HQ3-Is@psg.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 13 Oct 2008 14:16:53 +0200 (CEST)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

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

Hi Michael,

I think it is much simpler than that. The application is interested in
what is known with certainty.
1. It is certain the data is valid (secure)
2. It is certain that security checks failed (bogus)
3. whatever (insecure).

Thus, your numbers 1, 3, 5 are folded into insecure (or maybe more
accurately, 'no security available').

A mail application could deliver 1 and 3, but not 2(bogus).  Or it might
examine the AD bit on replies and only deliver 1.

When a DNAME or CNAME chain crosses a BOGUS entry, the DNAME or CNAME
chain result is bogus. When a DNAME or CNAME chain has all items secure,
the DNAME or CNAME chain result is secure.  All other cases are insecure
(i.e. the chain has one insecure element and the other elements are
insecure or secure).

I do not think a 'must be secure' bit is needed.  Only when all items in
the chain are secure is the result secure, and does the AD bit get set.

Best regards,
   Wouter

Michael StJohns wrote:
> At 01:36 AM 10/13/2008, Ben Laurie wrote:
>> 1. RR exists and here it is.
>> 2. RR does not exist.
>> 3. Server not reachable (or otherwise broken).
>>
>> to
>>
>> 1. RR exists and here it is.
>> 2. RR does not exist.
>> 3. RR exists but is broken in some way.
>> 4. Server not reachable (or otherwise broken).
> 
> I don't think its this simple... really.
> 
> Basic DNS has the 3 answers in your first group - although I'd categorize the last one as "I can't make any determination about whether or not the answer exists for any of a number of reasons" - what Marc describes as "indeterminate".
> 
> DNSSEC  add 4 (actually maybe even 5) security states that are somewhat orthogonal to the DNS states:
> 
> 1. Unknown - I've got no superior trust anchor so I can't make any definite statement about whether or not the answer is secure.
> 2.  Secure - I've gotten a chain of signatures covering which allow me to determine the answer is securely valid.
> 3.  Unsecure - I've gotten a chain of signature plus certain other data which tells me in a secure manner that I have no security information about the final answer.
> 4.  Bogus - I've gotten all the information I've asked for from the system, but I was unable to prove the security - bad signatures, missing keys, etc.
> 5.  Insecure transition from secure - I've got valid signatures as far as a CNAME or DNAME, but the CNAME or DNAME point into an area of the tree with Unknown trust.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkjzPDQACgkQkDLqNwOhpPg4hgCfZJrXXhwSeXgeZiU9W4FZ5Wwi
O84AoKnIBWKPbaVGzxeCueQWk5L0WslT
=tjtc
-----END PGP SIGNATURE-----

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>