Re: [DNSOP] The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state "Candidate for WG Adoption"
Shane Kerr <email@example.com> Fri, 06 November 2015 02:55 UTC
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3211B3453 for <firstname.lastname@example.org>; Thu, 5 Nov 2015 18:55:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([188.8.131.52]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZkwD-7s1NG6 for <email@example.com>; Thu, 5 Nov 2015 18:55:20 -0800 (PST)
Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE741B344D for <firstname.lastname@example.org>; Thu, 5 Nov 2015 18:55:19 -0800 (PST)
Received: from s20010c4000003032c68e8ffffef564bd.v6.meeting.ietf94.jp ([2001:c40:0:3032:c68e:8fff:fef5:64bd] helo=pallas.home.time-travellers.org) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <email@example.com>) id 1ZuXBK-00060G-RC for firstname.lastname@example.org; Fri, 06 Nov 2015 02:55:15 +0000
Date: Fri, 06 Nov 2015 11:55:06 +0900
From: Shane Kerr <email@example.com>
X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu)
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [DNSOP] The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state "Candidate for WG Adoption"
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Fri, 06 Nov 2015 02:55:22 -0000
Dear dnsop working group, On Thu, 05 Nov 2015 17:20:18 -0800 IETF Secretariat <firstname.lastname@example.org> wrote: > The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-ogud-dnsop-maintain-ds/ First, I definitely think that this should be a working group document. Second, some comments about the draft (with the hope that it does get adopted): * I think "all 0" CDS/CDNSKEY indicating desire for deletion is fine. Defining a DNSKEY algorithm that does not actually define a DNSKEY algorithm is a bit weird. * Perhaps a paragraph clarifying behavior when there is the "all 0" CDS/CDNSKEY AND another CDS/CDNSKEY record is a good idea? Something like: If any other CDS/CDNSKEY record is present in a zone, then the CDS/CDNSKEY records indicating deletion MUST be ignored. * The acceptance criteria for new CDS records seem less like a protocol definition and more like an exploration of possible approaches. Probably this is because that is what they are? :P Does it make sense to define more detail? I kind of think "yes", but since there is no deployment experience it's likely that it would all be incorrect. * I don't see much motivation for "Acceptance policy via authenticated channel". It seems like if you have access to such a channel you may as well just provide the DS record? Or is the idea that you make it so that the administrator for a zone doesn't need to cut/paste DS information but can just check a "delegate this" box? * Perhaps "Accept with challenge" should provide some advice on how this works. For example, a TXT record with a unique key for each zone (or customer) seems like a good recommendation. It might also make sense if each child domain (or customer) has a unique ownername to look for, to prevent 3rd parties from detecting such bootstrapping. (Yes a 3rd party can see the CDS update followed by the DS update, but they won't know the verification used.) Also to note that after the trust is established that the challenge record should no longer be necessary and can be removed. Sayōnara! -- Shane
- [DNSOP] The DNSOP WG has placed draft-ogud-dnsop-… IETF Secretariat
- Re: [DNSOP] The DNSOP WG has placed draft-ogud-dn… Shane Kerr
- Re: [DNSOP] The DNSOP WG has placed draft-ogud-dn… Olafur Gudmundsson
- Re: [DNSOP] The DNSOP WG has placed draft-ogud-dn… Jan Včelák
- Re: [DNSOP] The DNSOP WG has placed draft-ogud-dn… Jacques Latour