Hello all, (This also concerns the other discussion about "Negative Trust Anchors", I'll post with that subject as well)
-----Original Message----- From: Matthijs Mekking [mailto:[email protected]] ... > Not only that, also the entities on the authoritative side > don't have influence on the entities on the recursive side. Actually, there is something that influences the recursive side ! (I'm referring to 4.3.3 "Security lameness", where is state "removing a DS RR") Since this document is about "DNSSEC Operational Practices", perhaps include a suggestion that parents regularly (no frequency defined) check the coherence of DS information they have against DNSKEY information they find published. If the parent detects "security lameness" its possible reaction could be to remove the DS information. While my company, as registry for .eu, does not do this (yet ?), we do validate DNSSEC information when submitted, prior to publishing it as DS records (only if validation yields success). So, we already decide not to publish wrong information (at one point in time). The suggestion to regularly verify again extends that behaviour from "not publishing if wrong" (at submission time) to "stop publishing if wrong" (as part of normal operation) (the contract with registrars states that information provided by registrars must be correct. If not, the contract allows for some reactions (like blocking a domain in case of fake identities, but - by extension - to correctness of DNSSEC information) The advantage over negative trust anchor would be that this is more centrally managed : the action by the parent (remove DS) is visible (TTL permitted) to any validating name server. (the negative trust anchor needs to be configured by every validating NS, whose administrators bother to do so. And good point for Comcast who is obviously committed here !) I acknowledge that negative trust anchor applies to however the chain-of-trust starts (from the root-zone, or from some DLV). But since the root is DNSSEC'd since close to 2 years, I expect the DLV approach is less important anyway. Kind regards, Marc Lampo Security Officer EURid (for .eu) -----Original Message----- From: Matthijs Mekking [mailto:[email protected]] Sent: 12 April 2012 01:04 PM To: Marc Lampo Cc: [email protected] Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt -----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.t >>> x >>> >>> 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.tx >>> t > >>> >>> > > >>> _______________________________________________ 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
