On 18 feb 2011, at 12.06, Matthijs Mekking wrote: >> 1.2 Time Definitions: “Signature publication period” You mention that >> the replacement takes place in the master zone file. You are probably >> not manipulating the master zone file, but rather the data in the >> “signer”. Some solutions do write to a zone file, but is that always >> the case? You also mention that caches need to expire, etc. But it is >> not clear if this time is part of the definition of signature >> publication period or not. > > Would it be good enough to abstract from the master zone file, by just > referring to the zone? Proposed text: > > "Signature publication period" The period that a signature is > published. It starts at the time the signature is introduced in the > zone for the first time and ends at the time when the signature is > removed or replaced with a new signature.
Ok >> 1.2 Time Definitions: “Key effectivity period” I would define the key >> effectivity period as the time between creating the first signature >> and the last signature with this key. Remember that the inception >> time can be set to a time earlier than now because of the inception >> offset. And that key will become not active during a rollover, but >> the signatures may be reused for some extra days to get a smooth >> rollover of the signatures. So that you do not drop them at the same >> time. > > While technically it is true that a key becomes operative once it has > created the first signature, you could also say that for validators it > looks like that the key is in effect since the first signatures are > incepted. The signer pretends as if the key was in effect earlier than > the first signature was actually created. > > Not sure if this is important enough to argue about: We talk about key > effectivity periods of months, years and even decades. Ok >> 3.1 Operational Motivations (5th paragraph) Is it true that you get >> “operational flexibility and higher computational performance” by >> using a file based ZSK and smartcard KSK (offline in a safe) than a >> single key stored on an HSM? The HSM can give you the option to have >> the keys online, thus no need to take out the smartcard from the >> safe. And the HSM can be designed to give you speed. I know that my >> HSM is faster than OpenSSL on my machine. > > It may be unwise to talk about higher computational performance in this > section. The section motivates scenarios where operators may benefit > from a ZSK/KSK split. The 5th paragraph is worried about key compromise, > and how a split provides you more protection without losing too much of > your operational flexibility. Speed is not a motivation here. > > I do agree that 'on-line HSMs' marginalizes the argument in favor of the > split significantly. Ok >> 3.3 Key Effectivity Period (2nd paragraph) You say that you should >> choose 13 months as the KSK key effectivity period with the intent to >> replace it after 12 months. Why this extra month? The KSK key >> effectivity period is mostly just a policy. You do not know if you >> are able to complete all of the actions that are needed to do the >> rollover on that exact date. After the rollover, you can say that the >> effectivity period was e.g. 12.5 months because the interaction with >> your parent took some time. So before the rollover, the key >> effectivity period is a policy and after the rollover it is a fact. >> Nothing breaks if you take longer time. (The choice of 12 months is >> another discussion...) > > I agree. The key effectivity period should not be considered a constant > value. Do you want to start the discussion of 12 months now? ;) Lets have another email thread about that :) >> 3.4.1 Key Algorithm (2nd paragraph) “RSA/MD5 should not be” => >> “RSA/MD5 must not be” > > It is NOT RECOMMENDED in 4034, so I think the should is sufficient here. Ok >> 3.4.2 Key Sizes (1st paragraph) “can safely use 1024-bit keys for at >> least the next ten years”. NIST SP 800-131 says that 1024 – 2048 bit >> is acceptable to use in 2010. It is deprecated between 2011 and 2013. >> From 2011 you should use keys larger than 2048 bits. >> http://csrc.nist.gov/groups/ST/toolkit/documents/draftSP800-131_June_11_2010.pdf > > The recommendation is prepared for use by federal agencies. Is DNSSEC > required to follow these guidelines? We do not need to follow this, but it is good to have information from crypto experts. >> 3.4.2 Key Sizes (1st paragraph) Why mention the equivalent strength >> of a symmetric key if there is no other algorithm to compare with? > > It is compared with the typically next larger key size (2048 bits). > Should that comparison be removed as well? It is good as a reference on how strong RSA is compared with a symmetric key. But it would be more useful if there was a comparison between e.g. RSA and ECDSA. But ECDSA for DNSSEC is only a draft. So keep the text for now. >> 3.4.2 Key Sizes (2nd paragraph) “the next larger key size used is >> 2048 bits”. Is this a dramatic increase from 1024 bit, as the next >> larger key? There are more steps between 1024 and 2048 bits. > > It says typically. I am inclined to say that we do not have to go into > all possible key sizes. Ok >> 3.4.2 Key Sizes (2nd paragraph) Double the key size will make >> verification four times slower and signing eight times slower (not >> four times). “public key operations take O(k2) steps, private key >> operations take O(k3) steps, and key generation takes O(k4) steps” - >> http://www.rsa.com/rsalabs/node.asp?id=2215 > > But such notation might be to vaguely for operators. Yes, that was a copy of the text from RSA. It is just a reference for my argument that signing gets eight time slower and not four times. >> 3.4.3 Private Key Storage (2nd paragraph) Not only dynamic updates >> can require that you have “access” to one private key. It is more >> about regular / automatic updates. E.g. that your system push out a >> new zone file every second hour. No system administrator / security >> officer is willing to go to the server room regularly every day. > > Added ', or any other mechanism that runs at a regular interval'. Ok > I don't see a reason for having the private key on-line with your > regular update mechanism. Do you? The ZSK needs to be on-line. The KSK can be off-line. >> 4.2.1 KSK Compromise (2nd paragraph) A compromised KSK used by an >> attacker can also sign data in the zone other than the key set. An >> attacker does not need to follow the definitions of KSK vs ZSK. > > I am guessing that you aim for a small change here: to note that all > RRsets in the zone can be signed with the compromised KSK. I am tempted > not to add this because with a KSK compromise, the key set is > compromised anyway. Signing other RRsets is possible, but seems > arbitrary (like Jelte pointed out as well). Yes, ok. >> 4.2.1 and 4.2.2 What happens if both KSK and ZSK are compromised? In >> most deployments they are probably stored in the same location. > > You follow both guidelines described in 4.2.1 and 4.2.2? Ok >> 4.3.2 Storing Keys or Hashes (2nd paragraph) Why would storing the >> DNSKEY help troubleshooting, from a registry perspective? If it were >> to debug the conversion from DNSKEY to DS at registry level, then >> that would not be an argument to storing DNSKEY for troubleshooting, >> you would need the DNSKEY anyways. > > I don't seem to understand what your point is here... This section is about whether a registry should accept DS or DNSKEY from the registrar. And one of the arguments for receiving the DNSKEY was that it can be used for debugging. What do you want to debug? The only thing you can debug within the registry with the help of the DNSKEY, is in fact the conversion from DNSKEY to DS. But that is just a self fulfilling argument. E.g: "We want to receive the DNSKEY and not the DS, because we can then debug the conversion from DNSKEY to DS" >> 4.3.4 DS Signature Validity Period (2nd Paragraph) It probably does >> not matter how low the period is set in the parent’s policy. Some few >> hour or minutes is enough for an attacker to do damage. Long time >> before the child even considers switching the DS RR. > > Do you want to suggest text that should be included into this section? We probably can keep the original text. It at least tells the reader to think about this. >> 4.3.4 DS Signature Validity Period (3rd Paragraph) Is a period >> between a week and months a good compromise between the operation >> constraints of the parent and minimizing the damage for the child? >> You can do a lot of things during these months… > > You are arguing that the upper limit of months should be a lot lower. > That makes sense. Do you have suggestions? We probably can keep the original text. It at least tells the reader to think about this. >> 4.3.4 DS Signature Validity Period (4th Paragraph) Lower TTL does not >> help against replay attacks. > > But it does reduce the damage of a successful replay attack. Ok >> 4.4.1 Time Considerations (3rd bullet point) But it is ok to have 0s >> or 1s TTL for RR that are in the leafs of the DNS tree, right? > > Perhaps. You want that in the document? It might depend on the implementation. Maybe the BIND or Unbound people knows more about this. >> 4.4.2.2 Minimum Value (last paragraph) I would like to have more text >> about clock skew. It is important to talked about this since time in >> DNSSEC is not relative but absolute. E.g. that one hour for inception >> offset is ok, because if the clocks are more skewed than that, then >> other stuff will break down in your infrastructure. > > Do you want to provide text? From: "Note that in the figure the validity of the signature starts shortly before the inception time. That is done to deal with validators that might have some clock skew." To: "Note that in the figure the validity of the signature starts shortly before the signing time. That is done to deal with validators that might have some clock skew. The inception offset should be chosen so that you minimize the false negatives to a reasonable level." >> 4.4.2.4 Other timing parameters in a zone This text conflicts with >> the text in 4.4.1 (4th bullet point, 7th paragraph). Here you want >> the SOA expiration to be greater than the signature validity period. > > Should be equal to or lower than Refresh period. Yes. My comment "Here you want the ..." should have been written like this "The draft now say: It is advised to set the SOA expiration to a value greater than the signature validity period." >> 5.3.2 NSEC3 Iterations (2nd paragraph) You (NLnet Labs) recently >> published a report where large number of iterations made the name >> server less responsive. How would you compare the recommendation in >> this draft with the result from your report? > > The report was about the impact for name servers and validators in a > worst case scenario: all NXDOMAINs, very high iteration value. The > conlusion was that name servers dictate these parameters but are > affected the most as well. Because of being worst case scenario > research, I am not sure if the conclusions would fit into 4641bis. But it sounds quite high to follow the recommendation of choosing two-thirds of the maximum from the values 150 (1024 bit), 500 (2048 bit), and 2500 (4096 bit). A DDoS attack could query for domains that does not exist. You e.g. only get 50 % performance on NSD with the recommended value for 1024 bit keys and 25 % with the values for 2048 bit. // Rickard _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
