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 ?
About 2) So it is "two" steps ? 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 ... About 4) I can agree with the present text. 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. 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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.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 > [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/ iQEcBAEBAgAGBQJPerZ/AAoJEA8yVCPsQCW5m6AH/R9rFXjaAtHZLxIO7F1gC4rE 5AxO7ahIrzb1O7nNJhsAJ1HgTh1ViaOBPMlaU9UaCOKuvQ0jPJfD/aP/5WFFUz7Q DY0xeCCeQG0YO7NM1Z1O59DYXGsvvo2lkkDIPkITJG5G7hQJ+K7s/r+BF8tvQbtF Zzbcr3ZAG5jMyArrkGAogJUSZbQqc95pgYHzaeIxIiLZ4GuckrzDHraR4dke9DbW vK8GFmZFEjmhxrMH3kR/BQx5sHGj9pgQccoAIrNuWbJ8yT5HgtTD5kIh0IbE+RUG bPRPdF3G6A84U6szMnibB2SWchfiBdj0ncMMbeJQQ42miNlJsLJ0D505WlLECXQ= =0PCG -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
