Re: [DNSOP] Proposed changes to RFC 4641: rollovers
At 11:46 AM + 9/29/08, [EMAIL PROTECTED] wrote: your selection of 12-13 months and 25 years are suspect. Can you provide the underlaying bias for these tiemframes? The 12 month timeframe was adopted from the current 4641. I assume that this WG decided that, if you want to do rollovers to keep operational experience fresh in mind, that was the right period. Seems reasonable to me. The 25 years is based on experience from the web CA field, where the trust anchors are likely to be protected with the same tools as those that 4641 suggests high-value trust anchors for DNSSEC. As Wes pointed out, I conflated 25 years and never, which was a mistake. I like his replacement of ...effective longer than most operational environments exist without change, and 25 years seems to be a reasonable guess at that. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Proposed changes to RFC 4641: rollovers
Scott - Original Message - From: Scott Rose [EMAIL PROTECTED] To: dnsop@ietf.org Sent: Tuesday, September 30, 2008 4:07 AM Subject: Re: [DNSOP] Proposed changes to RFC 4641: rollovers On Sep 29, 2008, at 7:46 AM, [EMAIL PROTECTED] wrote: any KSK can be used as a TA. there is no way to know - unambigiously - that any given KSK is not being used as a TA in some validator. however, your assertion that at KSK should -never- be rolled unless compromise is known or strongly suspected is -BAD- from an operational and liklely from a trust perspective. your selection of 12-13 months and 25 years are suspect. Can you provide the underlaying bias for these tiemframes? That is actually the NIST recommendations in SP 800-57 part 1 Public keys used for authentication should have a use lifetime of 1-2 years, but can be kept around a little longer to validate pre-existing signatures after that period. Scott What do you mean Kept Around - those keys need to be re-creatable through some Key Recovery Proces. especially since the master DNS Root is a direct piece of US Government Property until the NTIA MOU is codified in a formal conveyance of those Intellectual Properties. Yes I am talking about the MOU that NTIA wrote under Nancy Victory Esq's hand several years ago. That said, since DNS Lookups and the records of them are key pieces of 'evidence of activity' on the Internet or as a part of a larger private secure IP Network mand stem from a US Government owned DNS Root, the Root and its operations are constrained by FISCAM and the requiremensts of FISMA here... So let me ask this, rather than ignoring the obvious why not look the use of DNS as a process to resolve an address and the handshaking processes in DNSSec provide the security model therein to meet the existing rules of evidence and step from there to the platform of needing to create culpable digital evidence that will meet the Presiding Court requirement's of any Nation willing to rely on this service??? This has ABSOLUTELY NOTHING to do with technology, it has to do with Social Process and that is the key win. We need logging of DNS Lookups that meets the reliable evidence requirement's put in place by the US Federal Rules of Civil Procedure. Todd Glassey --bill On Sun, Sep 28, 2008 at 09:14:34PM -0700, Paul Hoffman wrote: In the last paragraph of 3.1.1, remove the last sentence (Although, given a long enough key...). Replace it with the following paragraphs: There are two schools of thought on rolling a KSK that is not a trust anchor: - It should be done regularly (possibly every few months) so that a key rollover remains an operational routine. - It should only be done when it is known or strongly suspected that the key has been compromised in order to reduce the stability issues on systems where the rollover does not happen cleanly. There is no widespread agreement on which of these two schools of thought is better for different deployments of DNSSEC. There is a stability cost every time a non-anchor KSK is rolled over, but it is possibly low if the communication between the child and the parent is good. On the other hand, the only completely effective way to tell if the communication is good is to test it periodically. Thus, rolling a KSK with a parent is only done for two reasons: to test and verify the rolling system to prepare for an emergency, and in the case of an actual emergency. Because of the difficulty of getting all users of a trust anchor to replace an old trust anchor with a new one, a KSK that is a trust anchor should never be rolled unless it is known or strongly suspected that the key has been compromised. Remove the first paragraph of 3.3; it is now covered in 3.1.1 (and it was wrong about the cryptography). Change the second paragraph of 3.3 to: From a purely operational perspective, a reasonable key effectivity period for KSKs that have a parent zone is 13 months, with the intent to replace them after 12 months. An intended key effectivity period of a month is reasonable for Zone Signing Keys. This annual rollover gives operational practice to rollovers. Ignoring the operational perspective, a reasonable effectivity period for KSKs that have a parent zone is 25 years or longer. That is, if one does not plan to test the rollover procedure, the key should be effective essentially forever, and then only rolled over in case of emergency. In the first paragraph of 4.2, replace the first two sentences with: Regardless of whether a zone uses periodic key rollovers in order to practice for emergencies, or only rolls over keys in an emergency, key rollovers are a fact of life when using DNSSEC. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Proposed changes to RFC 4641: rollovers
All of those issues relate to separate topics beyond the current scope of this effort. I was only thinking of authentication for the protocol. Kept around means there could be signatures out there still valid (sig validity period in the RRSIG) and in cache when the private portion is no longer used to generate RRSIGs. Scott On Sep 30, 2008, at 11:26 AM, TS Glassey wrote: That is actually the NIST recommendations in SP 800-57 part 1 Public keys used for authentication should have a use lifetime of 1-2 years, but can be kept around a little longer to validate pre-existing signatures after that period. Scott What do you mean Kept Around - those keys need to be re-creatable through some Key Recovery Proces. especially since the master DNS Root is a direct piece of US Government Property until the NTIA MOU is codified in a formal conveyance of those Intellectual Properties. Yes I am talking about the MOU that NTIA wrote under Nancy Victory Esq's hand several years ago. That said, since DNS Lookups and the records of them are key pieces of 'evidence of activity' on the Internet or as a part of a larger private secure IP Network mand stem from a US Government owned DNS Root, the Root and its operations are constrained by FISCAM and the requiremensts of FISMA here... So let me ask this, rather than ignoring the obvious why not look the use of DNS as a process to resolve an address and the handshaking processes in DNSSec provide the security model therein to meet the existing rules of evidence and step from there to the platform of needing to create culpable digital evidence that will meet the Presiding Court requirement's of any Nation willing to rely on this service??? This has ABSOLUTELY NOTHING to do with technology, it has to do with Social Process and that is the key win. We need logging of DNS Lookups that meets the reliable evidence requirement's put in place by the US Federal Rules of Civil Procedure. Todd Glassey --bill On Sun, Sep 28, 2008 at 09:14:34PM -0700, Paul Hoffman wrote: In the last paragraph of 3.1.1, remove the last sentence (Although, given a long enough key...). Replace it with the following paragraphs: There are two schools of thought on rolling a KSK that is not a trust anchor: - It should be done regularly (possibly every few months) so that a key rollover remains an operational routine. - It should only be done when it is known or strongly suspected that the key has been compromised in order to reduce the stability issues on systems where the rollover does not happen cleanly. There is no widespread agreement on which of these two schools of thought is better for different deployments of DNSSEC. There is a stability cost every time a non-anchor KSK is rolled over, but it is possibly low if the communication between the child and the parent is good. On the other hand, the only completely effective way to tell if the communication is good is to test it periodically. Thus, rolling a KSK with a parent is only done for two reasons: to test and verify the rolling system to prepare for an emergency, and in the case of an actual emergency. Because of the difficulty of getting all users of a trust anchor to replace an old trust anchor with a new one, a KSK that is a trust anchor should never be rolled unless it is known or strongly suspected that the key has been compromised. Remove the first paragraph of 3.3; it is now covered in 3.1.1 (and it was wrong about the cryptography). Change the second paragraph of 3.3 to: From a purely operational perspective, a reasonable key effectivity period for KSKs that have a parent zone is 13 months, with the intent to replace them after 12 months. An intended key effectivity period of a month is reasonable for Zone Signing Keys. This annual rollover gives operational practice to rollovers. Ignoring the operational perspective, a reasonable effectivity period for KSKs that have a parent zone is 25 years or longer. That is, if one does not plan to test the rollover procedure, the key should be effective essentially forever, and then only rolled over in case of emergency. In the first paragraph of 4.2, replace the first two sentences with: Regardless of whether a zone uses periodic key rollovers in order to practice for emergencies, or only rolls over keys in an emergency, key rollovers are a fact of life when using DNSSEC. --Paul Hoffman, Director --VPN Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop === Scott Rose NIST [EMAIL PROTECTED] ph: +1 301-975-8439 http://www-x.antd.nist.gov/dnssec http://www.dnsops.gov/ ===
Re: [DNSOP] Proposed changes to RFC 4641: rollovers
On Sun, 28 Sep 2008 21:14:34 -0700, Paul Hoffman [EMAIL PROTECTED] said: Overall I think the changes seem reasonable. However, I don't think everything is taken into account... I understand the desire for removing the specified timing associated with key-age based on modern analysis. But there are other reasons for needing to roll keys besides just emergencies and emergency practice. Specifically: - algorithm changes (future algorithms may become more popular and supported by more tool sets than current ones) - key length changes required due to advances in cryptographic attacks - ownership changes (think of a zone name buy-out... the new owner will certainly not want to use the same key since I doubt they'll trust the original owner much but they will want to use it long enough for a reasonable properly timed rollover to occur). - parent relationship requirement changes (it's possible certain registrar's could enforce using a particular kind of key because that's how they're infrastructure is set up and if you change registrar's you may have to change your keying attributes). You make the assumption (in a few places) that you can control who uses your key as a trust anchor here. IE, if your parent is signed you shouldn't need to worry about your key as a trust-anchor. Although nice in theory, it may not meet real-world operational practice. In many cases it is probably true that your key will not be used as a TA, in other cases it's certainly false. PH Ignoring the operational perspective, a reasonable effectivity PH period for KSKs that have a parent zone is 25 years or longer. PH That is, if one does not plan to test the rollover procedure, the PH key should be effective essentially forever, and then only rolled ^^^ PH over in case of emergency. I agree that 25 years is long. I disagree, however, that it's safe to round it up to forever (infinite). Maybe wording along the lines of: ...effective longer than most operational environments exist without change or something like that, which is really what you're trying to imply by using 'forever'. -- In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find. -- Terry Pratchett ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
