-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Marc,
Sorry for the late response. On 04/19/2011 02:31 PM, Marc Lampo wrote: > Some comments : > > 3.1 Operational Motivation for ZSK and KSK > > I explicitly agree with Antoin Verschuren [[email protected]] that > more criteria should be taken into account, more then listed in the > present document (like the ones he proposes). I am not sure to which terminology you are referring to. Could you point me out? > As extra observation, I would prefer "child-parent" rather then > "registrar-registry" (globally : any reference to "registrar" or > "registry"). > Motivation : registrar is linked to the "customer" layer and "registry" to > the "tld" layer of a "customer.tld." domain name. But DNSSEC can go below > that level ! As I am in Belgium, "just.fgov.be." is a delegated subdomain > : if they will, one day, soon ?, implement DNSSEC, the communicating DS > information is not between registrar and registry. > In broader scope : the document should not limit to DNSSEC between a label > and a top-level-domain (or tld - root-domain). I am replacing the registrar-registry terms with child-parent on those places where the text is talking in a more general scope. > 4.1 Key Rollovers > > For non-tld's, I agree, again, with Antoin Verschuren > [[email protected]] : recommend double-sign rollover. > > The present document states, "neutrally", that double-sign rollover > involves more signatures and hence, larger zone files. While this is > true, well maintained (public) zone files should be small anyway (except > for tld's). > The average company does not offer hundreds of services on hundreds of IP > addresses. > > A DNS administrator who leaves data like "test-mx" in hers or his public > data should learn not to publish anything not meant to be distributed. > Recommending pre-publish for "large" zone files (with "lots" of > unnecessary data in it) is "pearls to the pigs" ;-) As said earlier by Paul and Antoin, I too am against such recommendation. > 4.1.2 Key Signing Rollovers > > I see some tld's perform rollover with 3 keys (not 2). > > Assuming a start position with 2 keys : > Initial : KSK1 & KSK2 (both being used for signing) > Start of rollover : add KSK3 --> KSK1 & KSK2 & KSK3 (all used for > signing) > End of rollover : remove KSK1 --> KSK2 & KSK3 (both used for signing) > Advantage : > Only 2 actions to complete key rollover > During the rollover, there is one key that is completely untouched. > --> if chain-of-trust would break via KSK1 or KSK3, that KSK2 > (DS/DNSKEY/RRSIG) is always available. > > As the KSK signs only the DNSKEY RRset, this "costs" only one extra RRSIG > in the zone file. To me, this sounds more like a Double-Signature Rollover variant, where there is a third key 'hanging around'. Thanks for your review. Best regards, Matthijs > > > Kind regards, > > Marc Lampo > > > > -----Original Message----- > From: Peter Koch [mailto:[email protected]] > Sent: 18 April 2011 07:42 PM > To: IETF DNSOP WG > Subject: [DNSOP] WGLC <draft-ietf-dnsop-rfc4641bis-06.txt> [2011-05-17] > > Dear DNSOP WG, > > this is to initiate a working group last call (WGLC) on > > "DNSSEC Operational Practices, Version 2" > <draft-ietf-dnsop-rfc4641bis-06.txt> > > Owing to the length of the document, the WGLC will last for four weeks > instead of the usual two, and will therefore end on > > Tuesday, 17 May, 23:59 UTC. > > The IETF tools site gives easy access to the current and previous > versions as well as differences and the like at > > <http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-06>. > > The document is aimed at a status of "Informational". > > Please review the document and send any comments you may have to the > list. If you have no comments but support (or do not support) the > document being published, please send that information to the list. > > The document is subject to the normal five reviewer threshold. > > Stephen and Peter > DNSOP co-chairs > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN3MxQAAoJEA8yVCPsQCW5n3EIALzqv2oKwR0kdVQrO4uXpfCm AlVoR+fd/Rg7CAProhFSVi0JmMxnfySyq3X/dJmFZXyMbPFFAdX8VjhmM3fy2NuU gHe0QydKQZ7UK9q+QWwJ+KVFkP2VEANrry4Wshr/hB3sVY3t1ya1QXu2fmhzLJgM yiekOYC70bVw0wAgxs7NyjxUOKI9qHLnSYoshe6LKvNdkVHvf/oiEhJzYjDNoUr1 +swPchNKHG7p7laTTe/+HWXkk+pW37fly5Jb8bpNBT8c0yj/Y8sTbUC5xYhthBRl u1MeDy4WWxMY7XBS3GkJAzsPi3x6vmKQIdjlFvKZ3pyc7byKWyU62qCd8bwq+uY= =svgT -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
