-----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
