-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Rickard,
On 02/22/2011 02:52 PM, Rickard Bellgrim 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. >>> 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. 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. 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). >>> 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). >>> 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." 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. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNZM9TAAoJEA8yVCPsQCW50VkH/1/lhGHV0zpdOXUfNmWHzV5f eb2x6MYeaYazNdbFR5nsTdwRoqBTGfTX0WlFzLAtw15vsdmGIBK3uuoDTWjJiRlW Ijh5oCXB4/eR8IVSefwnLwA+pShEpObnUsKXAsRpoL9OOUd5DIBZDTPTjFwvegFg IGwfqcSrwqobHa/e1F6pn/E2q1GWnZeY0UXGvdefHYCgTQhxizhzWE5d/IGz+KPF LYOhA8VYplL/duVXGBcsQC8nWOpgkOP6hmcxbwyRhceNTgygFIbgTt81PEB8kCMC JHF/exvZwNcilaI1v5mjKSelt4I2R2cC+C893ronkAXsS7eky+KhuT4BDjlJwUE= =cAwe -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
