Re: [dnsext] Reminder: two WGLC closing in one week
Michael StJohns <mstjohns@comcast.net> Mon, 22 September 2008 19:18 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 56C593A6924; Mon, 22 Sep 2008 12:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 SuNQKiyIUMw4; Mon, 22 Sep 2008 12:18:50 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 36A463A68A8; Mon, 22 Sep 2008 12:18:50 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KhqqB-000CE1-QD for namedroppers-data@psg.com; Mon, 22 Sep 2008 19:12:59 +0000
Received: from [76.96.62.80] (helo=QMTA08.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <mstjohns@comcast.net>) id 1Khqpz-000CBT-Ig for namedroppers@ops.ietf.org; Mon, 22 Sep 2008 19:12:54 +0000
Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA08.westchester.pa.mail.comcast.net with comcast id HtGw1a0030SCNGk58vCmQj; Mon, 22 Sep 2008 19:12:46 +0000
Received: from MIKES-LAPTOM.comcast.net ([69.140.151.110]) by OMTA09.westchester.pa.mail.comcast.net with comcast id HvCm1a0012P9w053VvCmX9; Mon, 22 Sep 2008 19:12:46 +0000
X-Authority-Analysis: v=1.0 c=1 a=gwu2n-TYGH0A:10 a=YzQq6kKhkNwA:10 a=10CFcY03AAAA:8 a=48vgC7mUAAAA:8 a=u5a2LfwBhSmIZTcEm2UA:9 a=PjsY7fHXG7qXn_yWYUYA:7 a=8RNpLrwcvMASnrYyUyHO2SDCLJEA:4 a=GEO3fhvhlRQA:10 a=50e4U0PicR4A:10
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 22 Sep 2008 15:12:44 -0400
To: Andrew Sullivan <ajs@commandprompt.com>, namedroppers@ops.ietf.org
From: Michael StJohns <mstjohns@comcast.net>
Subject: Re: [dnsext] Reminder: two WGLC closing in one week
In-Reply-To: <20080919004547.GD2037@commandprompt.com>
References: <20080919004547.GD2037@commandprompt.com>
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: <E1KhqqB-000CE1-QD@psg.com>
Hi Andrew - At Scott's request I took a look at the dname document. Keep in mind that I'm looking at it pretty much for the first time. Unfortunately, I don't think its ready for prime-time. Most of the document is fine - but the section on DNSSEC is woefully lacking. DNSSEC unfortunately makes things more difficult. Having DNAMEs plus DNSSEC stretches the complications almost to the breaking. The section needs more than a 1 page description of why DNSSEC servers need to understand DNAME, it needs a discussion of the various combinations of modes in which a resolver can find itself when following a DNAME chain. For example - what happens if the DNAME is signed, but the referenced target isn't? What happens if both are signed, but the resolver doesn't have a trust anchor for the target but has one for the DNAME? For the DNAME but not the target? What happens if the DNAME is directly reachable (e.g. querier is a validating recursive resolver) but the target is available only through a forwarder? What happens if the DNAME and the target are signed with different algorithm and the querier only understands one of they. I can see about a number of different ways to have different resolvers behave given different combinations. I think they need to be called out and a specific behavior proposed for each prior to sending this forward. One proposal, once the "must be signed bit" is set (e.g. DNAME or target subordinate to a trust anchor without a delegation to unsecure), then ALL data must be signed to be considered valid. (Not sure this is the right way of doing things, but its a conversation starter). Sorry - Mike At 08:45 PM 9/18/2008, Andrew Sullivan wrote: >Dear colleagues, > >This is a reminder that there are two outstanding WGLC open, and that >they both expire in one week. They are for the following two >documents: > >draft-ietf-dnsext-rfc2672bis-dname-14.txt > >draft-ietf-dnsext-dnssec-rsasha256-05.txt > >The WGLC for both of these have already been extended in order to >address concerns that many people were on vacation in August. By my >count, we're not quite to the threshold of reviewers with either of >these. _PLEASE read them and comment_, or else, by the conventions >adopted by the working group, they'll have to die as far as the >working group is concerned. Given that we took both of these on as WG >items, we owe it to our colleagues who have worked on them to perform >the review. > >Thanks, and best regards, > >Andrew (for the chairs) > >-- >Andrew Sullivan >ajs@commandprompt.com >+1 503 667 4564 x104 >http://www.commandprompt.com/ > >-- >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/> -- 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