-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/12/2012 02:09 PM, Marc Lampo wrote: > 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")
Sorry that I didn't make myself clear, perhaps influence was a bad word here. Of course the changes you make in your zone influences the recursive side. What I (and the document) try to make clear is that entities on the authoritative side do not have influence on *the operations* at the recursive side. Are there more people who think the text in the introduction is confusing? If so, please speak up and preferably suggest other wordings. Furthermore, we are shifting away from your review item (1), which was about the text in the introduction. You are now talking about security lameness. There are already considerations about that topic in 4641bis. Your suggestion is already there, see Section 4.3.3! Best regards, Matthijs > > 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 > > 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 > > _______________________________________________ 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/ iQEcBAEBAgAGBQJPhstQAAoJEA8yVCPsQCW55K0H/1VJWKaDEmA9m3liyJb3aib1 28oC3zy3/PsEHyhz5B4HPN7vwi2Hg8j9EFIgu7UZYyn7nYG5MVvfnUZTgHXYg/zr 5nTFDckITbUk0gRO3IyMhBmXx5GVySot4vBNDH7vi0TQXUQ9QMvpqsnzllCplhTb sRaEtLNku2SzoMCJtkKYsrdsXWUtgU+AQwq3Ik+WwdM2L79FjypKKpwrmL6xbvSM setOYGOeD88wdrR3InQ/PGkYOtpmGBHxRvG6G89vVbnpzeCAbZ4un91pZIcbYfuY FEbwxfbvsC09jrIEWhkQz88T6xyDH0wTi75hkcmcElB4hasfAaTBDmQdjAj+Pdo= =pIOC -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
