-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/12/2012 12:48 PM, Marc Lampo wrote: > Hello Matthijs, > > Regarding 1 - "... no relationship ... validating ... " > > Suggestion (a phrase that does not hint at any possible > "relationship") : This document holds no information that applies > to the configuration of validating recursive name servers > (validators).
Not only that, also the entities on the authoritative side don't have influence on the entities on the recursive side. > > Ok regarding 2 : three stages > > OK regarding 3 : consequences for validation by parents > > (as a matter of fact, we're going to check if we adapt our present > validation ourselves) > > For 4 and 5 there was already an OK. > > Kind regards, > > Marc > > > -----Original Message----- From: Matthijs Mekking > [mailto:[email protected]] Sent: 12 April 2012 10:53 AM To: > Marc Lampo Cc: [email protected] Subject: Re: [DNSOP] I-D Action: > draft-ietf-dnsop-rfc4641bis-10.txt > > 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:[email protected]] Sent: 03 April 2012 10:36 AM To: >> Marc Lampo Cc: [email protected] 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: [email protected] >>> [mailto:[email protected]] Sent: 30 March 2012 11:36 AM >>> To: [email protected] Cc: [email protected] 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.tx >>> >>> t > >>> 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 [email protected] >>> https://www.ietf.org/mailman/listinfo/dnsop > >> _______________________________________________ DNSOP mailing >> list [email protected] https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ 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/ iQEcBAEBAgAGBQJPhraeAAoJEA8yVCPsQCW5t54IANHgx1Kb01ifNjkFKn5eUaUd ku9oS8d7JdW+7Bt2ps+vTQeec4oUqZ4x6HcFJj38TRxFwHXoyTVL06UVtzLV8btG KQbAlTgYPbuxS5uE/BqAUXFeqtItLqbSvKHmD2GLMtKBm8/hRYpNYIfwn184Svmi /BHJxu0FQrRB0wCF5FCEsYasXRrd/JISaiNqGlyzBETQbCZl02RMUpvCu4RdLNy0 kz2EiBrxkkpvqoMlWRKv6ejR5MfhX07otzPTWWBTTu/ugIjcVxqCojjv299Mj1Oq nmjzrpm3C6hBFPhoYen6HXcpJQziZ5wM/c6hZqoJIAXUmhCyh/DGHNbCMcEaCJk= =2548 -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
