Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME
Michael StJohns <mstjohns@comcast.net> Mon, 13 October 2008 16:26 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 83C553A68BA; Mon, 13 Oct 2008 09:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.14
X-Spam-Level:
X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 87Fblo6jWSR2; Mon, 13 Oct 2008 09:26:46 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 55F433A683A; Mon, 13 Oct 2008 09:26:46 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KpQD3-000NAr-3l for namedroppers-data@psg.com; Mon, 13 Oct 2008 16:23:53 +0000
Received: from [76.96.30.80] (helo=QMTA08.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <mstjohns@comcast.net>) id 1KpQCv-000NA5-Eg for namedroppers@ops.ietf.org; Mon, 13 Oct 2008 16:23:47 +0000
Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id SF1x1a00y0cQ2SLA8GPUwR; Mon, 13 Oct 2008 16:23:28 +0000
Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id SGPR1a00E2P9w058WGPSHJ; Mon, 13 Oct 2008 16:23:28 +0000
X-Authority-Analysis: v=1.0 c=1 a=dmE0DmLRt_UA:10 a=-5nm-dUE1uIA:10 a=wCfa3VrZFAKm5OSuh3wA:9 a=ASmL2TMms_bRjqjcFbD9HZaKs1gA:4 a=h9s5Ru71U4oA:10
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 13 Oct 2008 12:23:25 -0400
To: Wouter Wijngaards <wouter@NLnetLabs.nl>
From: Michael StJohns <mstjohns@comcast.net>
Subject: Re: [dnsext] flip-flopping secure and unsecure DNAME/CNAME
Cc: Ben Laurie <ben@links.org>, Edward Lewis <Ed.Lewis@neustar.biz>, namedroppers@ops.ietf.org
In-Reply-To: <48F33C34.3010901@nlnetlabs.nl>
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> <48F33C34.3010901@nlnetlabs.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
Message-Id: <E1KpQD3-000NAr-3l@psg.com>
At 08:16 AM 10/13/2008, Wouter Wijngaards wrote: >-----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'). This is why doing the bigger matrix and trying to do the decomposition into handling states is probably the right approach - your later email changes this based on further discussion but still doesn't quite get all the states covered. >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. The AD bit gets set (or not) when you return data from a recursive nameserver, but that doesn't really describe how an application doing its own DNSSEC validation should handle this type of data. It may be that your approach of if anything is bogus its all bogus, else if everything is secure its all secure, else its unsecure is correct. BUT - this seems at odds with the general DNSSEC contract that says we don't transition to an unsecure state unless we do it securely. If I'm the zone owner of the zone with the DNAME, and I'd doing a reference to another zone that - at the time I did the delegation - I knew to be secure, shouldn't I expect that DNSSEC should flag it if someone tries to resolve this and finds an unsecure zone? Again if not, why not? And why isn't this as much of a downgrade attack as all the other various schemes that have been described to me? Mike >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/>
- [dnsext] Reminder: two WGLC closing in one week Andrew Sullivan
- Re: [dnsext] Reminder: two WGLC closing in one we… Scott Rose
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Edward Lewis
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- DNAME (and CNAME) vs DNSSEC (Was: [dnsext] Remind… Andrew Sullivan
- Re: [dnsext] Reminder: two WGLC closing in one we… Michael StJohns
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- [dnsext] Re: DNAME (and CNAME) vs DNSSEC Wes Hardaker
- Re: DNAME (and CNAME) vs DNSSEC (Was: [dnsext] Re… Edward Lewis
- [dnsext] recommeded contents for Re: DNAME (and C… Edward Lewis
- [dnsext] flip-flopping secure and unsecure DNAME/… Edward Lewis
- Re: [dnsext] recommeded contents for Re: DNAME (a… Scott Rose
- [dnsext] Re: DNAME (and CNAME) vs DNSSEC Wes Hardaker
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: [dnsext] flip-flopping secure and unsecure DN… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… John Dickinson
- Re: [dnsext] Reminder: two WGLC closing in one we… Florian Weimer
- Re: [dnsext] Reminder: two WGLC closing in one we… Mark Andrews
- Re: [dnsext] Reminder: two WGLC closing in one we… Florian Weimer
- Re: [dnsext] Reminder: two WGLC closing in one we… Olafur Gudmundsson
- Re: [dnsext] flip-flopping secure and unsecure DN… Edward Lewis
- the DO bit Re: [dnsext] Reminder: two WGLC closin… Edward Lewis
- Re: the DO bit Re: [dnsext] Reminder: two WGLC cl… bmanning
- Re: the DO bit Re: [dnsext] Reminder: two WGLC cl… David Conrad
- Re: [dnsext] flip-flopping secure and unsecure DN… Ben Laurie
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: [dnsext] flip-flopping secure and unsecure DN… Wouter Wijngaards
- Re: [dnsext] flip-flopping secure and unsecure DN… Ben Laurie
- Re: [dnsext] flip-flopping secure and unsecure DN… Alex Bligh
- Re: [dnsext] flip-flopping secure and unsecure DN… Ben Laurie
- CNAME/DNAME - Re: [dnsext] flip-flopping secure a… Edward Lewis
- Re: [dnsext] flip-flopping secure and unsecure DN… Shane Kerr
- Re: [dnsext] flip-flopping secure and unsecure DN… Alex Bligh
- Interpreting DNSSEC was Re: [dnsext] flip-floppin… Edward Lewis
- Re: [dnsext] flip-flopping secure and unsecure DN… Nicholas Weaver
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Alex Bligh
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: CNAME/DNAME - Re: [dnsext] flip-flopping secu… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: [dnsext] flip-flopping secure and unsecure DN… Michael StJohns
- Re: CNAME/DNAME - Re: [dnsext] flip-flopping secu… Edward Lewis
- Re: CNAME/DNAME - Re: [dnsext] flip-flopping secu… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Ben Laurie
- Re: CNAME/DNAME - Re: [dnsext] flip-flopping secu… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Ben Laurie
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Nicholas Weaver
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Mark Andrews
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Wouter Wijngaards
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Ben Laurie
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Mark Andrews
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Michael StJohns
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Stephane Bortzmeyer
- Re: Interpreting DNSSEC was Re: [dnsext] flip-flo… Edward Lewis