On 23 feb 2011, at 10.11, Matthijs Mekking wrote: >>>> 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. > > True. But my point is that NIST is a guideline for local policy. This > document targets a larger audience.
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" > > So should we remove the paragraph? (The section will just recommend > storing DS records, and optionally DNSKEY records (e.g. if the > registrars don't allow for uploading DS records). Yes, but the second part of the paragraph: "Having an out-of-band mechanism, such as a registry directory (e.g., Whois), to find out which keys are used to generate DS Resource Records for specific owners and/or zones may also help with troubleshooting." is more relevant and helpful. Maybe it can be used in another context in the draft. Because you could also display the DS RRs in the Whois. >>>> 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. > > I guess we could say that data at the leafs has less impact on recursive > nameservers than data at delegation points (regarding frequent > verification). Ok >>>> 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. > > Ah ok. The report does point out that the half performance count on > nameservers (or at least NSD) in worst case scenarios is about 100 > iterations, regardless of the key size. So perhaps the recommendation > should in 4641bis should take that into account. Yes // Rickard _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
