Hi Olaf Sorry for this long email, but I got some comments on your draft: “DNSSEC Operational practices”. It is a good draft this is needed, just want to clarify some stuff.
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. 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. 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. 3.2 Practical Consequences (2nd paragraph) The statement is that you can have signature validity periods on the order of days for ZSK signatures, because there is no interaction with the parent during a key rollover. Well this is not true. There is nothing that prevents you from having short validity periods for KSK signatures. ZSK and KSK is thus equal in that aspect. 3.2 Practical Consequences (3rd paragraph) During a KSK rollover, there will be “interactions with parties other than the zone administrator”. This sounds like there is an interaction with the zone administrator during a ZSK rollover. It is true if you have an offline KSK. But ZSK rollover can be automated if you have the KSK online in e.g. an HSM. I would suggest removing the last part of the statement. 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...) 3.3 Key Effectivity Period (4th paragraph) Ok, in a lab it might be possible to do rollovers every few minutes. But in the real world, your DNSKEY RRset would grow really big because of pre- and post-publishing of the key (depending on your rollover mechanism). And this document is almost like a BCP, should we tell people that this is possible? 3.4.1 Key Algorithm (1st paragraph) Don’t forget to mention GOST and that DSA (in DNSSEC) is limited to maximum 1024 bit keys. 3.4.1 Key Algorithm (2nd paragraph) “RSA/MD5 should not be” => “RSA/MD5 must not be” 3.4.2 Key Sizes This section talks about key sizes, but that depends on what algorithm you are talking about. Please mention RSA somewhere. 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 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? 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. 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 3.4.2 Key Sizes (5th paragraph) DSA in general can have larger keys than 1024, but it is limited to 1024 bits in DNSSEC. 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. 3.4.3 Private Key Storage (last paragraph) See arguments above. How does this paragraph then fit in? 3.4.4 Key Generation HSM:s also provide a good facility for key generation. With good random numbers. 4.1 Key Rollovers I would STRONGLY suggest that you minimize this section. Just give an overview of how the different rollover methods function and compare them with each other. Refer to the key timing draft, so that we do not get the timings in two documents. 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. 4.2.1.1 Keeping the Chain of Trust Intact (1st paragraph) Why do we want to make the key set expire in the caches by lowering the signature lifetime? Caching is based on the minimum of TTL and remaining signature lifetime, right? Why not use a lower TTL on DNSKEY? Less to tweak in the signer. 4.2.1.2 Breaking the Chain of Trust (2nd paragraph) Isn’t this method just breaking your own zone. Not the one that the attacker has? See the last paragraph in 4.2.1. 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. 4.2.3 Compromises of keys Anchored in Resolvers (1st paragraph) Shouldn’t we think the DNSSEC deployment in the root as successful? 4.3.1 Initial Key Exchange I also think that it should be possible to send in a DS RR for which there is no DNSKEY in the child zone. I know that there are registries that disallow this and others allow this. The reason is to not limit any (future) rollover mechanism. What we could say is that there should be at least one of the DS RRs pointing to a DNSKEY. 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. 4.3.3 Security Lameness (2nd paragraph) No, the parent should allow DS RR pointing to non-published DNSKEY. We should not limit any (future) rollover mechanisms. There should of course be at least one DS pointing to one DNSKEY. 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. 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… 4.3.4 DS Signature Validity Period (4th Paragraph) Lower TTL does not help against replay attacks. 4.3.5 Changing DNS Operators (1st paragraph) This is not the definition of a thin registry. It is a definition of a registry-registrar model. 4.3.5.1 Cooperating DNS operators Isn’t the Double-DS method better than the double signature KSK rollover in this case? You only share DNSKEY RRset with each other. Not sharing signatures. 4.4.1 Time Considerations (2nd bullet point) Ok, this means that you are reusing the signature up to the point where there is only one maximum zone TTL left. If your signing or distribution system breaks down, then you only have that time to fix it. Can you fix your system within these few hours? Is four days more reasonable? See 4.4.2.2 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? 4.4.1 Time Considerations (4th bullet point, 7th paragraph) The SOA expiration timer should not be compared with signature validity period, but with the refresh period (- resign period). 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. 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. 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? 5.3.3 NSEC3 Salt (3rd paragraph) You recommend doing re-salting at the same time as ZSK rollover. But it is not required to drop all signatures at once during a ZSK rollover. This can be a smooth transition determined by the refresh period. Appendix A – Key Size Yes in RSA you use the modulus size to determine the key size. But it does not apply to other algorithms. Appendix A – Refresh Period New definition: The time before the expiration of the signature where it is not reused anymore. Appendix C Move this to the key timing draft. Finally: You are missing text about standby keys. Used to speed up the rollover in case of an emergency. But also as part of your disaster recovery, when you have lost access to your keys and the backups cannot be restored. This is how you do it: 1. Generate standby KSK and ZSK. Store them safely. 2. Prepublish standby ZSK in zone. 3. Prepublish DS of standby KSK in parent zone. 4. You have a disaster. 5. Create a new datacenter and import the standby keys. 6. Postpublish old ZSK in zone (fetch it from a secondary somewhere). 7. Sign and publish zone. 8. After "some" TTL remove old ZSK and old DS 9. Continue with normal operation. // Rickard _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
