-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Marc,
Coming back to your review items, I only think point 1 is not decided on yet. But I don't think this should stop progress. You can find my responses in between lines. Best regards, Matthijs On 04/03/2012 11:11 AM, Marc Lampo wrote: > Hello again, > > About 1) If the document is for the authoritative side, why not > simply state so. Instead of this confusing statement about > relationship between authoritative and validating NS's ? I believe it does state so, without confusion: The first sentence says the document is aimed for people that are active at the authoritative side. The second sentence says that we consider no relationship with the people running the recursive side. You think the document can do without the latter sentence. I think it is a fair assumption. > About 2) So it is "two" steps ? I made it three stages. ;) > About 3) I forgot the word "corresponding", my fault there. As such > the text is not wrong, please don't misunderstand me. But the > parent the only way, for a parent, to known/verify that DS > information is correct, is by querying for the DNSKEY RRset and > check if the corresponding ( ;-) DNSKEY is indeed present. If it is > not, there is no way the parent can distinguish between a child > zone administrator performing a double-DS rollover or making an > error ... The text is not wrong, so we do not need action for 4641bis here. My point of view on this topic: As long as there is a valid DS with corresponding DNSKEY, adding another DS is no error. Maybe you are afraid what happens if the child zone operator removes the old DNSKEY and replaces it with the new (mismatched) one. Now you have encountered the error. But such things are not specific to Double-DS rollover, it can happen also without being in a rollover: I could remove my DNSKEYs from my zone, and it would go bogus. Same thing. My point is, as long as the zone is able to be validated, there is no error made (in terms of DNSSEC). > About 4) I can agree with the present text. Ok. > About 5) Me too, I think published signatures should never be > expired. Consequently, every key rollover will make signatures > disappear that are, as such, not expired yet. From that point of > view it makes little difference if signature validity period is a > couple of weeks or months or years. > > But if the zone administrator uses long validity time with the > intention not to recalculate regularly, this implies that the ZSK > cannot rollover either. (and this is practice - out there, right > now ! There is one TLD that has signatures valid till "the end of > the current year", and never did any key rollover since it started > with DNSSEC) > > To conclude : I can "just" agree with the present text. Ok. > > > > Kind regards, > > Marc Lampo EURid (for .eu) > > -----Original Message----- From: Matthijs Mekking > [mailto:matth...@nlnetlabs.nl] Sent: 03 April 2012 10:36 AM To: > Marc Lampo Cc: dnsop@ietf.org Subject: Re: [DNSOP] I-D Action: > draft-ietf-dnsop-rfc4641bis-10.txt > > Hi, > > On 04/02/2012 04:35 PM, Marc Lampo wrote: >> Hello to the list, > >> Nice piece of work ! > >> Some remarks - nothing spectacular : 1) Last sentence in the >> first paragraph - Introduction (about : "no direct relation >> between ... and validating caching name servers.") > >> Isn't this sentence superfluous ? I fail to see where a possible >> relation would indeed change something to these guidelines. > >> But by including the sentence about no relationship, one starts >> to wonder if something escapes me ... > > The document just tries to make it very clear that it is targeted > to the authoritative side of the DNS equation. > > >> 2) Double Signature ZSK rollover in 4.1.1.3 The last sentence >> states there are three steps. I think this is an error : There >> are three states, yes; but there are only two manipulations to >> perform. (to me it seems logical to interpret "step" as : >> "operation to perform") > > Sure. More important is the fact that it is one step/stage shorter > than Pre-publish ZSK rollover. > >> 3) 4.1.3 Difference between ZSK and KSK rollovers 4.3.3 Security >> Lameness > >> (actually, 4.1.3 introduces another way of KSK rollover. In that >> respect the title of the section is confusing !) > >> In 4.1.3 the text suggest to publish a DS record in the parent >> for which there is no DNSKEY record in the child zone. > > It suggests to publish a DS record for which there is no > *corresponding* DNSKEY record in the child zone, next to an > existing chain of trust between parent and child. That is different > from "no DNSKEY record in the child zone". > >> In 4.3.3 the text suggest the parent could verify that the DNSKEY >> is actually published by the child. > >> --> 4.3.3 could explicitly state that, if a parent performs this >> kind of checking, then the "double DS method" of 4.1.3 is not >> possible. > > There is already a forward reference in section 4.1.3 to 4.3.3. > >> Furthermore : as registry (for .eu) we think that it is important >> to assist our registrars in setting DNSSEC up correctly. >> Consequently, we do verification when a registrar sends us DNSSEC >> information. So we cannot distinguish between a DNS Operator >> that performs double DS KSK rollover and an operator making a >> mistake ... > > I think you might have a false negative there: If a DNS operator > requests for a second DS to be published, it does not break the > chain of trust. Why classify it as a mistake? Double-DS rollover is > perfectly acceptable within the boundaries of DNSSEC. > >> 4) 4.3.4 DS Signature Validity Period The last paragraph holds a >> sentence that states : "Shortening the TTL reduces the damage of >> a successful replay attack." > >> I don't think this is correct (or relevant). For me, the chances >> for a replay attack increase with the signature validity period, >> not with the value of the TTL. The value of the paragraph lays, >> for me, in the propagation of updated DS RRsets (cfr the >> presentation on low TTL's, last week). > > You are right that the chances for a replay attack increase with > the validity period, but the damage depends on how long that data > will be in the cache. That depends on TTL. > >> 5) 4.4.2.1 Maximum value (for Signature Validation Period) > >> I think this paragraph should make a reference to Key Rollover ! >> Motivation : no matter how long a signature is valid, in order >> for it to be used, the corresponding Key must be available. (so : >> if the reason for long RRSIG validity is not to recalculate them, >> then ...) > >> I do admit that none of the Key Rollover scenario's take into >> account the signature validity time (but the TTL). And indeed, >> nothing prevents to generate a signature, valid for 1 year, with >> TTL of 1 day, and perform key rollover every three months : the >> still valid signature simply times out of the cache, to be >> replaced by a new one, valid for a new year. > > Hence, I don't think this paragraph should make a reference to key > rollover. > > Best regards, Matthijs > > >> Kind regards, > >> Marc Lampo EURid (for .eu) > > >> -----Original Message----- From: internet-dra...@ietf.org >> [mailto:internet-dra...@ietf.org] Sent: 30 March 2012 11:36 AM >> To: i-d-annou...@ietf.org Cc: dnsop@ietf.org Subject: [DNSOP] >> I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt > > >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. This draft is a work item of the >> Domain Name System Operations Working Group of the IETF. > >> Title : DNSSEC Operational Practices, Version 2 >> Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename >> : draft-ietf-dnsop-rfc4641bis-10.txt Pages : 78 Date : >> 2012-03-30 > >> This document describes a set of practices for operating the DNS >> with security extensions (DNSSEC). The target audience is zone >> administrators deploying DNSSEC. > >> The document discusses operational aspects of using keys and >> signatures in the DNS. It discusses issues of key generation, >> key storage, signature generation, key rollover, and related >> policies. > >> This document obsoletes RFC 4641 as it covers more operational >> ground and gives more up-to-date requirements with respect to key >> sizes and the DNSSEC operations. > > >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt > >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt > >> > > >> _______________________________________________ DNSOP mailing >> list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org 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/ iQEcBAEBAgAGBQJPhpfSAAoJEA8yVCPsQCW52YUH/0eUw4cd20SZSbD79E//K1eo UwauNqTKZT+r1GuGSqFUXpCTgBrZVLvALmdVzGrK8dA6WuifNSU6aimZvf9csgWO bpRS1ty3xWMA88BFZ7sLFT4rYT9FT7S7jBgpZ8BfYWgZRGPvqIQpXn9EKT6Y8r8g blI0QUbFRxd+WUagSAZNK+QEWLlm8EdXWKA4sn/TlVAx/jYImQt7nRGCZj+MHG8W mnSDr1p8w16J3DYOqUSlmvj/YfgSF0yS+WPMusEWmAPJSiYpmx8G4/3OAXqKWF9t 11FZySeN0eqBuFIr1fYwpITLFHpxzgc9F0aEdST/7vJpZDFMfNk66ScRHxs6rvU= =oMto -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
