-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Rickard,
A long email deserves a long response:) On 11/08/2010 05:51 PM, Rickard Bellgrim wrote: > 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. 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. > 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. > 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. > 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. I agree. Paul Wouters responded: "It depends on how long the parent's DS/NS records are valid for (TTL) and how fast they can update the DS record. It's not fully in your control, so there is some possible delay (and you NEED a monitor to avoid a bad rollover)", but I think that is more related to KSK rollover, not the KSK signature validity period. > 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. I agree. > 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? ;) > 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? Although perhaps considered a BCP by some, it is informational. But I agree that this short paragraph doesn't add much. > 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. Ok. > 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. > 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. Yes. > 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? > 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? > 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. > 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. > 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. Ok. > 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'. > 3.4.3 Private Key Storage (last paragraph) See arguments above. How > does this paragraph then fit in? I don't see a reason for having the private key on-line with your regular update mechanism. Do you? > 3.4.4 Key Generation HSM:s also provide a good facility for key > generation. With good random numbers. Added the note. > 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. If I am correct, you are referring to the tables. I believe there is still strong consensus to keep the tables in here. The tables do not really go into timing parameters imho, they merely talk about TTL intervals. > 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). > 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. I agree. Then you would not have to do lowering signature validity periods at all. > 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. The attacker is still able to spoof the child's zone until the DS is replaced in the parent, yes. > 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? > 4.2.3 Compromises of keys Anchored in Resolvers (1st paragraph) > Shouldn’t we think the DNSSEC deployment in the root as successful? Removed the line "For instance, if DNSSEC is successfully deployed...". But I still think this section has value. > 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. Yes. > 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... > 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. The section does not prohibit it. It actually mentions the rollover scheme that may be used. > 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? > 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? > 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. > 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. ok. > 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. If the registry and registrars for security lame DS records, then yes. I will add text. > 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 Yes, will add the operational havoc consideration here too. > 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? > 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). Ok. > 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? > 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. > 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. > 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. ok. > 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. ok. > Appendix A – Refresh Period New definition: The time before the > expiration of the signature where it is not reused anymore. ok. > Appendix C Move this to the key timing draft. Consensus was that tables should stay. > 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. Ok. Thanks for the extensive review. Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNXlLKAAoJEA8yVCPsQCW5bLkH/jeAW4Cy2YXD6pENk9IrhS34 IbPyR3fMxwORrlGPzP8MHDYPj98q21NxIWlhsk+2HGO1rkj2eltb1qeS5bsMm3Wl sJrQHkDIrtVdImEGXPNN7q55zWJk1iPXB32OmxNWnwHcNMCNP/YKcSVGt6NvSXrP P//rOHCWxx2fOtooM5erttmRJtF7AGpDf8J46BsBMhRv8MCaj2ugreWpvKGxEkEv uyLFoPxxb4yQDCFbCs1opyksefHumgWXioHDe9uLqGcExFI246bKqdZg8hRKfqqs GlpPL0t0nZyjiV6j14zGPcitPe9VvB+BUyRk3nByl9YpGiWybGTqLbsNpuzZtFk= =txlg -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
