[ksk-change] Helping the panel name the reasons for the KSK rollover
When considering how and when to rollover the root KSK, the community also have to consider why. In the past, many different reasons were given by various community members, and other community members have stated disagreements with some or all of those reasons. Thus, in order to make the how and when decision clearer to the community, the new KSK rollover panel needs to make explicit the reasoning for a particular rollover design. The following are the most common reasons that have been given for why to roll over the root KSK. They are given using mildly positive language, and no counter-arguments are given. Each has a short-hand title to help facilitate the panel's thinking. If there are other reasons that someone in the community feels strongly about, it should be brought up so that the panel can consider it as well. --Paul Hoffman DPS statement -- Section 6.5 of the DPS for the root zone says that the KSK will be rolled over after five years of operation, and that time has already passed. Cryptographic aging -- The longer a public key is known to an attacker, the longer the attacker has to determine the private key. HSM aging -- The hardware signing modules (HSMs) used for the root key have a guaranteed life of five years, and that time has already passed. Operational practice for ICANN -- It is good to test the steps of a key rollover so that the holders of the key have practice; this helps prevent mistakes during future rollovers. Operational practice for operators -- It is good to test the steps of a getting new KSKs so that the users of the key have practice; this helps prevent mistakes during future KSK retrievals. Change to ECDSA/P256 -- The ECDSA/P256 signing algorithm is both stronger than RSA/2048 and had better operational properties, and changing the KSK to use this will cause wider adoption throughout the DNSSEC community.
Wondering if the rare case of the root KSK being discovered to be compromised should also get a mention in that list. Are not the others just precaution to avoid this case, or there are other steps when this happens? Thanks Ashu -----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Paul Hoffman Sent: Monday, February 23, 2015 20:45 To: ksk-rollover@icann.org Subject: [ksk-change] Helping the panel name the reasons for the KSK rollover When considering how and when to rollover the root KSK, the community also have to consider why. In the past, many different reasons were given by various community members, and other community members have stated disagreements with some or all of those reasons. Thus, in order to make the how and when decision clearer to the community, the new KSK rollover panel needs to make explicit the reasoning for a particular rollover design. The following are the most common reasons that have been given for why to roll over the root KSK. They are given using mildly positive language, and no counter-arguments are given. Each has a short-hand title to help facilitate the panel's thinking. If there are other reasons that someone in the community feels strongly about, it should be brought up so that the panel can consider it as well. --Paul Hoffman DPS statement -- Section 6.5 of the DPS for the root zone says that the KSK will be rolled over after five years of operation, and that time has already passed. Cryptographic aging -- The longer a public key is known to an attacker, the longer the attacker has to determine the private key. HSM aging -- The hardware signing modules (HSMs) used for the root key have a guaranteed life of five years, and that time has already passed. Operational practice for ICANN -- It is good to test the steps of a key rollover so that the holders of the key have practice; this helps prevent mistakes during future rollovers. Operational practice for operators -- It is good to test the steps of a getting new KSKs so that the users of the key have practice; this helps prevent mistakes during future KSK retrievals. Change to ECDSA/P256 -- The ECDSA/P256 signing algorithm is both stronger than RSA/2048 and had better operational properties, and changing the KSK to use this will cause wider adoption throughout the DNSSEC community. _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Feb 23, 2015, at 7:21 AM, Kumar Ashutosh <askuma@microsoft.com> wrote:
Wondering if the rare case of the root KSK being discovered to be compromised should also get a mention in that list.
That is part of "Operational practice for ICANN".
Are not the others just precaution to avoid this case, or there are other steps when this happens?
Some people would argue that some of the other reasons are precautions to avoid KSK compromise, others would argue that they are unrelated. --Paul Hoffman
I’d like to offer some re-wording. I may have misunderstood of the points below were summaries of what has been said elsewhere (hence “data points”) or whether this is a summary if what’s been said. So let me know if my suggestions are jumping the gun. On 2/23/15, 10:14, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
When considering how and when to rollover the root KSK, the community also have to consider why. In the past, many different reasons were given by various community members, and other community members have stated disagreements with some or all of those reasons. Thus, in order to make the how and when decision clearer to the community, the new KSK rollover panel needs to make explicit the reasoning for a particular rollover design.
The following are the most common reasons that have been given for why to roll over the root KSK. They are given using mildly positive language, and no counter-arguments are given. Each has a short-hand title to help facilitate the panel's thinking. If there are other reasons that someone in the community feels strongly about, it should be brought up so that the panel can consider it as well.
--Paul Hoffman
DPS statement -- Section 6.5 of the DPS for the root zone says that the KSK will be rolled over after five years of operation, and that time has already passed.
This connotes that the roll is over due, or about to be. The wording is “after 5 years” and not “within 5 years.” I wasn’t part of this discussion, so perhaps there are those with a different memory than what is printed, but the words here tell me the “clock” in a roll starts after we have 5 years (and I’ll add “of experience running DNSSEC.”) So, I’d suggest changing to “5 years has lapsed” instead of “that time has already passed.” (Note, I would consider 6.5’s operation to begin in July 2010, a quibble, so we haven’t quite reached the 5 year horizon but we are certainly close enough to say we have. I note this to perhaps clear up when “operations” began - if we need to.)
Cryptographic aging -- The longer a public key is known to an attacker, the longer the attacker has to determine the private key.
I would have thought “the longer and more often a public key is in use, the greater the chance cryptanalysis can be performed to discern the private key.” (And you could throw in that the more the key is put to use, the greater the chance it could be lost - hardware hits a bump and zeros - or it could be stolen - someone walks off with the healthy HSM.) I think it’s helpful to separate the failure modes of keys (exposed/discovered, reverse engineered, lost, copied, stolen and whatever else) so we don’t "keep tripping over these cords.” My list probably duplicates scenarios.
HSM aging -- The hardware signing modules (HSMs) used for the root key have a guaranteed life of five years, and that time has already passed.
I think this is a misstatement. I don’t want to confuse the story further so I won’t offer corrective text but encourage someone more familiar with the lifetime of components (particularly the batteries).
Operational practice for ICANN -- It is good to test the steps of a key rollover so that the holders of the key have practice; this helps prevent mistakes during future rollovers.
And prepares one for un-scheduled (emergency) changes.
Operational practice for operators -- It is good to test the steps of a getting new KSKs so that the users of the key have practice; this helps prevent mistakes during future KSK retrievals.
And prepares one for un-scheduled (emergency) changes.
Change to ECDSA/P256 -- The ECDSA/P256 signing algorithm is both stronger than RSA/2048 and had better operational properties, and changing the KSK to use this will cause wider adoption throughout the DNSSEC community.
And, if I understand this correctly, smaller response sizes, a important facet for DNS. I haven’t confirmed this myself and hope that someone who has numbers can contribute to this.
Just want to point out that "scheduled rollover of the KSK" was an original basic requirement when DNSSEC was implemented at the root. Specifically (as referenced in the baseline requirements, with the footnote 12, http://www.ntia.doc.gov/files/ntia/publications/dnssec_requirements_102909.p...): "c) Root Zone KSK Rollover i) Scheduled rollover of the RZ KSK shall be performed.12 12 The Department envisions the timeline for scheduled rollover of the RZ KSK to be jointly developed and proposed by ICANN and VeriSign, based on consultation and input from the affected parties (e.g. root server operators, large-scale resolver operators, etc). Note that subsequent test plans may specify more or less frequent RZ KSK rollover to ensure adequate testing." -----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Edward Lewis Sent: Monday, February 23, 2015 10:40 AM To: Paul Hoffman; ksk-rollover@icann.org Subject: Re: [ksk-change] Helping the panel name the reasons for the KSK rollover I’d like to offer some re-wording. I may have misunderstood of the points below were summaries of what has been said elsewhere (hence “data points”) or whether this is a summary if what’s been said. So let me know if my suggestions are jumping the gun. On 2/23/15, 10:14, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
When considering how and when to rollover the root KSK, the community also have to consider why. In the past, many different reasons were given by various community members, and other community members have stated disagreements with some or all of those reasons. Thus, in order to make the how and when decision clearer to the community, the new KSK rollover panel needs to make explicit the reasoning for a particular rollover design.
The following are the most common reasons that have been given for why to roll over the root KSK. They are given using mildly positive language, and no counter-arguments are given. Each has a short-hand title to help facilitate the panel's thinking. If there are other reasons that someone in the community feels strongly about, it should be brought up so that the panel can consider it as well.
--Paul Hoffman
DPS statement -- Section 6.5 of the DPS for the root zone says that the KSK will be rolled over after five years of operation, and that time has already passed.
This connotes that the roll is over due, or about to be. The wording is “after 5 years” and not “within 5 years.” I wasn’t part of this discussion, so perhaps there are those with a different memory than what is printed, but the words here tell me the “clock” in a roll starts after we have 5 years (and I’ll add “of experience running DNSSEC.”) So, I’d suggest changing to “5 years has lapsed” instead of “that time has already passed.” (Note, I would consider 6.5’s operation to begin in July 2010, a quibble, so we haven’t quite reached the 5 year horizon but we are certainly close enough to say we have. I note this to perhaps clear up when “operations” began - if we need to.)
Cryptographic aging -- The longer a public key is known to an attacker, the longer the attacker has to determine the private key.
I would have thought “the longer and more often a public key is in use, the greater the chance cryptanalysis can be performed to discern the private key.” (And you could throw in that the more the key is put to use, the greater the chance it could be lost - hardware hits a bump and zeros - or it could be stolen - someone walks off with the healthy HSM.) I think it’s helpful to separate the failure modes of keys (exposed/discovered, reverse engineered, lost, copied, stolen and whatever else) so we don’t "keep tripping over these cords.” My list probably duplicates scenarios.
HSM aging -- The hardware signing modules (HSMs) used for the root key have a guaranteed life of five years, and that time has already passed.
I think this is a misstatement. I don’t want to confuse the story further so I won’t offer corrective text but encourage someone more familiar with the lifetime of components (particularly the batteries).
Operational practice for ICANN -- It is good to test the steps of a key rollover so that the holders of the key have practice; this helps prevent mistakes during future rollovers.
And prepares one for un-scheduled (emergency) changes.
Operational practice for operators -- It is good to test the steps of a getting new KSKs so that the users of the key have practice; this helps prevent mistakes during future KSK retrievals.
And prepares one for un-scheduled (emergency) changes.
Change to ECDSA/P256 -- The ECDSA/P256 signing algorithm is both stronger than RSA/2048 and had better operational properties, and changing the KSK to use this will cause wider adoption throughout the DNSSEC community.
And, if I understand this correctly, smaller response sizes, a important facet for DNS. I haven’t confirmed this myself and hope that someone who has numbers can contribute to this.
On Feb 23, 2015, at 8:11 AM, Ashley Heineman <AHeineman@ntia.doc.gov> wrote:
Just want to point out that "scheduled rollover of the KSK" was an original basic requirement when DNSSEC was implemented at the root. Specifically (as referenced in the baseline requirements, with the footnote 12, http://www.ntia.doc.gov/files/ntia/publications/dnssec_requirements_102909.p...):
"c) Root Zone KSK Rollover
i) Scheduled rollover of the RZ KSK shall be performed.12
12 The Department envisions the timeline for scheduled rollover of the RZ KSK to be jointly developed and proposed by ICANN and VeriSign, based on consultation and input from the affected parties (e.g. root server operators, large-scale resolver operators, etc). Note that subsequent test plans may specify more or less frequent RZ KSK rollover to ensure adequate testing."
Is that subsumed by "DPS statement -- Section 6.5 of the DPS for the root zone says that the KSK will be rolled over after five years of operation, and that time has already passed.", or do you consider the contents of that footnote a separate issue? --Paul Hoffman
Both ZSK and KSK DPSs were written and cleared by all the root zone management partners design team (VRSN, ICANN, NTIA) so I believe DPSs and requirements documents are consistent with each other. That was my understanding...we would roll but when was up for discussion. Do you see a contradiction? Happy to hear what others think. I am not the best at details like Jakob+Fredrik were. -Rick -----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Paul Hoffman Sent: Monday, February 23, 2015 5:30 PM To: Ashley Heineman Cc: ksk-rollover@icann.org Subject: Re: [ksk-change] Helping the panel name the reasons for the KSK rollover On Feb 23, 2015, at 8:11 AM, Ashley Heineman <AHeineman@ntia.doc.gov> wrote:
Just want to point out that "scheduled rollover of the KSK" was an
original basic requirement when DNSSEC was implemented at the root. Specifically (as referenced in the baseline requirements, with the footnote 12, http://www.ntia.doc.gov/files/ntia/publications/dnssec_requirements_102909.p df):
"c) Root Zone KSK Rollover
i) Scheduled rollover of the RZ KSK shall be performed.12
12 The Department envisions the timeline for scheduled rollover of the RZ KSK to be jointly developed and proposed by ICANN and VeriSign, based on consultation and input from the affected parties (e.g. root server operators, large-scale resolver operators, etc). Note that
subsequent test plans may specify more or less frequent RZ KSK rollover to ensure adequate testing."
Is that subsumed by "DPS statement -- Section 6.5 of the DPS for the root zone says that the KSK will be rolled over after five years of operation, and that time has already passed.", or do you consider the contents of that footnote a separate issue? --Paul Hoffman _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
FWIW - NTIA considers them separate documents and do not see a contradiction. The baseline requirements are exactly that (baseline requirements) and the DPS was one mechanism by which the RZM partners worked to fulfill / and flesh out the requirements. My recollection is that, at the outset, we all agreed that there would be "scheduled" rollovers. The issue was that we (NTIA-NIST) didn't want to bind the partners with a pre-cooked schedule or notion of what the schedule should be as this was kind of unchartered waters at the time, but recognized the need for rollovers and that the issue of what "schedule" they would be on needed to be thoroughly discussed, considered, and potentially reconsidered. -----Original Message----- From: Richard Lamb [mailto:richard.lamb@icann.org] Sent: Monday, February 23, 2015 11:41 AM To: Paul Hoffman; Ashley Heineman Cc: ksk-rollover@icann.org Subject: RE: [ksk-change] Helping the panel name the reasons for the KSK rollover Both ZSK and KSK DPSs were written and cleared by all the root zone management partners design team (VRSN, ICANN, NTIA) so I believe DPSs and requirements documents are consistent with each other. That was my understanding...we would roll but when was up for discussion. Do you see a contradiction? Happy to hear what others think. I am not the best at details like Jakob+Fredrik were. -Rick -----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Paul Hoffman Sent: Monday, February 23, 2015 5:30 PM To: Ashley Heineman Cc: ksk-rollover@icann.org Subject: Re: [ksk-change] Helping the panel name the reasons for the KSK rollover On Feb 23, 2015, at 8:11 AM, Ashley Heineman <AHeineman@ntia.doc.gov> wrote:
Just want to point out that "scheduled rollover of the KSK" was an
original basic requirement when DNSSEC was implemented at the root. Specifically (as referenced in the baseline requirements, with the footnote 12, http://www.ntia.doc.gov/files/ntia/publications/dnssec_requirements_102909.p df):
"c) Root Zone KSK Rollover
i) Scheduled rollover of the RZ KSK shall be performed.12
12 The Department envisions the timeline for scheduled rollover of the RZ KSK to be jointly developed and proposed by ICANN and VeriSign, based on consultation and input from the affected parties (e.g. root server operators, large-scale resolver operators, etc). Note that
subsequent test plans may specify more or less frequent RZ KSK rollover to ensure adequate testing."
Is that subsumed by "DPS statement -- Section 6.5 of the DPS for the root zone says that the KSK will be rolled over after five years of operation, and that time has already passed.", or do you consider the contents of that footnote a separate issue? --Paul Hoffman _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
The assumption was a HSM replace before 5 years (to be conservative since minimum battery life is 5 years according to spec sheet*) ...and - given strong interest by the community for exercising KSK rollover early on - KSK roll at same time given we would be replacing the HSM anyway. Not so much because the KSK might be compromised but to exercise the process and understand the effects sooner rather than later. So the wording in the DPS specifically doesn’t say the KSK must be rolled. *attached. The manufacturer has said this was a conservative estimate based on tamper circuitry current draw so even if battery date code - which are stamped on the rear of the units - preceded purchase dates, we should be ok. I understand we are replacing HSMs in April so this should no longer be an issue. -----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Edward Lewis Sent: Monday, February 23, 2015 4:40 PM To: Paul Hoffman; ksk-rollover@icann.org Subject: Re: [ksk-change] Helping the panel name the reasons for the KSK rollover I’d like to offer some re-wording. I may have misunderstood of the points below were summaries of what has been said elsewhere (hence “data points”) or whether this is a summary if what’s been said. So let me know if my suggestions are jumping the gun. On 2/23/15, 10:14, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
When considering how and when to rollover the root KSK, the community also have to consider why. In the past, many different reasons were given by various community members, and other community members have stated disagreements with some or all of those reasons. Thus, in order to make the how and when decision clearer to the community, the new KSK rollover panel needs to make explicit the reasoning for a particular rollover design.
The following are the most common reasons that have been given for why to roll over the root KSK. They are given using mildly positive language, and no counter-arguments are given. Each has a short-hand title to help facilitate the panel's thinking. If there are other reasons that someone in the community feels strongly about, it should be brought up so that the panel can consider it as well.
--Paul Hoffman
DPS statement -- Section 6.5 of the DPS for the root zone says that the KSK will be rolled over after five years of operation, and that time has already passed.
This connotes that the roll is over due, or about to be. The wording is “after 5 years” and not “within 5 years.” I wasn’t part of this discussion, so perhaps there are those with a different memory than what is printed, but the words here tell me the “clock” in a roll starts after we have 5 years (and I’ll add “of experience running DNSSEC.”) So, I’d suggest changing to “5 years has lapsed” instead of “that time has already passed.” (Note, I would consider 6.5’s operation to begin in July 2010, a quibble, so we haven’t quite reached the 5 year horizon but we are certainly close enough to say we have. I note this to perhaps clear up when “operations” began - if we need to.)
Cryptographic aging -- The longer a public key is known to an attacker, the longer the attacker has to determine the private key.
I would have thought “the longer and more often a public key is in use, the greater the chance cryptanalysis can be performed to discern the private key.” (And you could throw in that the more the key is put to use, the greater the chance it could be lost - hardware hits a bump and zeros - or it could be stolen - someone walks off with the healthy HSM.) I think it’s helpful to separate the failure modes of keys (exposed/discovered, reverse engineered, lost, copied, stolen and whatever else) so we don’t "keep tripping over these cords.” My list probably duplicates scenarios.
HSM aging -- The hardware signing modules (HSMs) used for the root key have a guaranteed life of five years, and that time has already passed.
I think this is a misstatement. I don’t want to confuse the story further so I won’t offer corrective text but encourage someone more familiar with the lifetime of components (particularly the batteries).
Operational practice for ICANN -- It is good to test the steps of a key rollover so that the holders of the key have practice; this helps prevent mistakes during future rollovers.
And prepares one for un-scheduled (emergency) changes.
Operational practice for operators -- It is good to test the steps of a getting new KSKs so that the users of the key have practice; this helps prevent mistakes during future KSK retrievals.
And prepares one for un-scheduled (emergency) changes.
Change to ECDSA/P256 -- The ECDSA/P256 signing algorithm is both stronger than RSA/2048 and had better operational properties, and changing the KSK to use this will cause wider adoption throughout the DNSSEC community.
And, if I understand this correctly, smaller response sizes, a important facet for DNS. I haven’t confirmed this myself and hope that someone who has numbers can contribute to this.
Oops...attachment -----Original Message----- From: Richard Lamb Sent: Monday, February 23, 2015 5:17 PM To: Edward Lewis; Paul Hoffman; ksk-rollover@icann.org Subject: RE: [ksk-change] Helping the panel name the reasons for the KSK rollover The assumption was a HSM replace before 5 years (to be conservative since minimum battery life is 5 years according to spec sheet*) ...and - given strong interest by the community for exercising KSK rollover early on - KSK roll at same time given we would be replacing the HSM anyway. Not so much because the KSK might be compromised but to exercise the process and understand the effects sooner rather than later. So the wording in the DPS specifically doesn’t say the KSK must be rolled. *attached. The manufacturer has said this was a conservative estimate based on tamper circuitry current draw so even if battery date code - which are stamped on the rear of the units - preceded purchase dates, we should be ok. I understand we are replacing HSMs in April so this should no longer be an issue. -----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Edward Lewis Sent: Monday, February 23, 2015 4:40 PM To: Paul Hoffman; ksk-rollover@icann.org Subject: Re: [ksk-change] Helping the panel name the reasons for the KSK rollover I’d like to offer some re-wording. I may have misunderstood of the points below were summaries of what has been said elsewhere (hence “data points”) or whether this is a summary if what’s been said. So let me know if my suggestions are jumping the gun. On 2/23/15, 10:14, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
When considering how and when to rollover the root KSK, the community also have to consider why. In the past, many different reasons were given by various community members, and other community members have stated disagreements with some or all of those reasons. Thus, in order to make the how and when decision clearer to the community, the new KSK rollover panel needs to make explicit the reasoning for a particular rollover design.
The following are the most common reasons that have been given for why to roll over the root KSK. They are given using mildly positive language, and no counter-arguments are given. Each has a short-hand title to help facilitate the panel's thinking. If there are other reasons that someone in the community feels strongly about, it should be brought up so that the panel can consider it as well.
--Paul Hoffman
DPS statement -- Section 6.5 of the DPS for the root zone says that the KSK will be rolled over after five years of operation, and that time has already passed.
This connotes that the roll is over due, or about to be. The wording is “after 5 years” and not “within 5 years.” I wasn’t part of this discussion, so perhaps there are those with a different memory than what is printed, but the words here tell me the “clock” in a roll starts after we have 5 years (and I’ll add “of experience running DNSSEC.”) So, I’d suggest changing to “5 years has lapsed” instead of “that time has already passed.” (Note, I would consider 6.5’s operation to begin in July 2010, a quibble, so we haven’t quite reached the 5 year horizon but we are certainly close enough to say we have. I note this to perhaps clear up when “operations” began - if we need to.)
Cryptographic aging -- The longer a public key is known to an attacker, the longer the attacker has to determine the private key.
I would have thought “the longer and more often a public key is in use, the greater the chance cryptanalysis can be performed to discern the private key.” (And you could throw in that the more the key is put to use, the greater the chance it could be lost - hardware hits a bump and zeros - or it could be stolen - someone walks off with the healthy HSM.) I think it’s helpful to separate the failure modes of keys (exposed/discovered, reverse engineered, lost, copied, stolen and whatever else) so we don’t "keep tripping over these cords.” My list probably duplicates scenarios.
HSM aging -- The hardware signing modules (HSMs) used for the root key have a guaranteed life of five years, and that time has already passed.
I think this is a misstatement. I don’t want to confuse the story further so I won’t offer corrective text but encourage someone more familiar with the lifetime of components (particularly the batteries).
Operational practice for ICANN -- It is good to test the steps of a key rollover so that the holders of the key have practice; this helps prevent mistakes during future rollovers.
And prepares one for un-scheduled (emergency) changes.
Operational practice for operators -- It is good to test the steps of a getting new KSKs so that the users of the key have practice; this helps prevent mistakes during future KSK retrievals.
And prepares one for un-scheduled (emergency) changes.
Change to ECDSA/P256 -- The ECDSA/P256 signing algorithm is both stronger than RSA/2048 and had better operational properties, and changing the KSK to use this will cause wider adoption throughout the DNSSEC community.
And, if I understand this correctly, smaller response sizes, a important facet for DNS. I haven’t confirmed this myself and hope that someone who has numbers can contribute to this.
On 2/23/2015 11:18 AM, Richard Lamb wrote:
Oops...attachment
For me, I'm not all that worried about batteries unless the design of this thing is way different that other HSMs. Most HSMs have a three tier power system - line power, battery backup, capacitor. Only the capacitor is within the tamper boundary and it's there primarily to allow the battery to be replaced without zeroizing the HSM. The spec sheet didn't actually provide enough information to evaluate the above, but if this is the case, then it might be time to think about replacing the backup battery. Later, Mike
-----Original Message----- From: Richard Lamb Sent: Monday, February 23, 2015 5:17 PM To: Edward Lewis; Paul Hoffman; ksk-rollover@icann.org Subject: RE: [ksk-change] Helping the panel name the reasons for the KSK rollover
The assumption was a HSM replace before 5 years (to be conservative since minimum battery life is 5 years according to spec sheet*) ...and - given strong interest by the community for exercising KSK rollover early on - KSK roll at same time given we would be replacing the HSM anyway. Not so much because the KSK might be compromised but to exercise the process and understand the effects sooner rather than later. So the wording in the DPS specifically doesn’t say the KSK must be rolled.
*attached. The manufacturer has said this was a conservative estimate based on tamper circuitry current draw so even if battery date code - which are stamped on the rear of the units - preceded purchase dates, we should be ok. I understand we are replacing HSMs in April so this should no longer be an issue.
-----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Edward Lewis Sent: Monday, February 23, 2015 4:40 PM To: Paul Hoffman; ksk-rollover@icann.org Subject: Re: [ksk-change] Helping the panel name the reasons for the KSK rollover
I’d like to offer some re-wording. I may have misunderstood of the points below were summaries of what has been said elsewhere (hence “data points”) or whether this is a summary if what’s been said. So let me know if my suggestions are jumping the gun.
On 2/23/15, 10:14, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
When considering how and when to rollover the root KSK, the community also have to consider why. In the past, many different reasons were given by various community members, and other community members have stated disagreements with some or all of those reasons. Thus, in order to make the how and when decision clearer to the community, the new KSK rollover panel needs to make explicit the reasoning for a particular rollover design.
The following are the most common reasons that have been given for why to roll over the root KSK. They are given using mildly positive language, and no counter-arguments are given. Each has a short-hand title to help facilitate the panel's thinking. If there are other reasons that someone in the community feels strongly about, it should be brought up so that the panel can consider it as well.
--Paul Hoffman
DPS statement -- Section 6.5 of the DPS for the root zone says that the KSK will be rolled over after five years of operation, and that time has already passed. This connotes that the roll is over due, or about to be. The wording is “after 5 years” and not “within 5 years.” I wasn’t part of this discussion, so perhaps there are those with a different memory than what is printed, but the words here tell me the “clock” in a roll starts after we have 5 years (and I’ll add “of experience running DNSSEC.”) So, I’d suggest changing to “5 years has lapsed” instead of “that time has already passed.” (Note, I would consider 6.5’s operation to begin in July 2010, a quibble, so we haven’t quite reached the 5 year horizon but we are certainly close enough to say we have. I note this to perhaps clear up when “operations” began - if we need to.)
Cryptographic aging -- The longer a public key is known to an attacker, the longer the attacker has to determine the private key. I would have thought “the longer and more often a public key is in use, the greater the chance cryptanalysis can be performed to discern the private key.” (And you could throw in that the more the key is put to use, the greater the chance it could be lost - hardware hits a bump and zeros - or it could be stolen - someone walks off with the healthy HSM.)
I think it’s helpful to separate the failure modes of keys (exposed/discovered, reverse engineered, lost, copied, stolen and whatever else) so we don’t "keep tripping over these cords.” My list probably duplicates scenarios.
HSM aging -- The hardware signing modules (HSMs) used for the root key have a guaranteed life of five years, and that time has already passed. I think this is a misstatement. I don’t want to confuse the story further so I won’t offer corrective text but encourage someone more familiar with the lifetime of components (particularly the batteries).
Operational practice for ICANN -- It is good to test the steps of a key rollover so that the holders of the key have practice; this helps prevent mistakes during future rollovers. And prepares one for un-scheduled (emergency) changes.
Operational practice for operators -- It is good to test the steps of a getting new KSKs so that the users of the key have practice; this helps prevent mistakes during future KSK retrievals. And prepares one for un-scheduled (emergency) changes.
Change to ECDSA/P256 -- The ECDSA/P256 signing algorithm is both stronger than RSA/2048 and had better operational properties, and changing the KSK to use this will cause wider adoption throughout the DNSSEC community. And, if I understand this correctly, smaller response sizes, a important facet for DNS. I haven’t confirmed this myself and hope that someone who has numbers can contribute to this.
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
Hi Jacques, A document is in development by the the IANA team (which is different than the KSK design team). Not sure what the publication timeline is. Regards, -drc -----Original Message----- From: Jacques Latour <jacques.latour@cira.ca> Date: Monday, February 23, 2015 at 9:55 AM To: Richard Lamb <richard.lamb@icann.org>, Edward Lewis <edward.lewis@icann.org>, Paul Hoffman <paul.hoffman@vpnc.org>, "ksk-rollover@icann.org" <ksk-rollover@icann.org> Subject: Re: [ksk-change] Helping the panel name the reasons for the KSK rollover
Rick,
Do you have more details on the procedure for replacing the HSM?
I understand we are replacing HSMs in April so this should no longer be an issue.
ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On 2/23/2015 10:40 AM, Edward Lewis wrote:
HSM aging -- The hardware signing modules (HSMs) used for the root key
have a guaranteed life of five years, and that time has already passed. I think this is a misstatement. I don’t want to confuse the story further so I won’t offer corrective text but encourage someone more familiar with the lifetime of components (particularly the batteries).
This one is probably the most critical and the least understood of the reasons for doing a trust anchor update. The assumption you have to make is there is no way to move the private key from one HSM technology to another, and that there is no guarantee that the current HSM vendor will be in place to support their HSM for any given time. The reality may end up being different (e.g. there may actually be a way of extracting the private key from within the HSM policy boundary - which has its own issues, or the HSM vendor lives on for 20-30 years and is willing to support the same class of HSM device), but we have to deal with the worst case scenarios. There are basically two sub issues for HSM aging: a) HSM support. This is basically what Paul wrote. Hardware has a finite lifetime. The HSM vendor guaranteed the current devices for 5 years and we're past that. Over the next 5 years we can expect failures in power supplies, chassis components and maybe even the core security processor. Failure of the former will require existence of replacement parts and service knowledge. Failure of the latter *MAY* result in the private key becoming unavailable. Redundancy is your friend here and having two of these is useful, but at some point we're going to have to migrate from the current generation of HSM to the next - either the same vendor or someone else - as support for the current devices becomes problematic. That migration is made simpler if we do not need to transfer the existing private key to the new technology. b) HSM vulnerability. The other problem with HSM aging is that security technology is always going to be an arms race. Breaking into a circa 2005 HSM design to extract the key is generally going to be easier in 2015. Moving to a new HSM designed to defeat new threats (e.g. various sensor and scanning technologies, fault injection, tamper detection defeats to prevent zeroization, etc) seems prudent every so often. Again, migration to new technology is simplified if we do not need to transfer the existing private key. So a new reason for trust anchor update: HSM key migration considered harmful. If you have to extradite a private key from one technology for injection in another - at some point the private key (encrypted or not) is vulnerable in the wild. There are ways to mitigate the vulnerabilities, but not to completely eliminate them. There are ways to generate a key pair and clone them safely (cryptographically safe, not just hardware safe) at the time of generation to multiple HSMs, but doing this after the fact requires updating the policy wrapping the signing key in a manner that could be attacked (e.g. you shouldn't be able to update the HSM code without wiping the keys).
On Feb 23, 2015, at 7:40 AM, Edward Lewis <edward.lewis@icann.org> wrote:
I’d like to offer some re-wording. I may have misunderstood of the points below were summaries of what has been said elsewhere (hence “data points”) or whether this is a summary if what’s been said.
If I was not completely clear that they were summaries, I apologize. Hopefully, no one in this discussion would think that a single sentence would express what took many rounds of email to explain the first time.
So let me know if my suggestions are jumping the gun.
Note that I explicitly said twice that this was input to the panel; I don't get to (or want to!) gate the input at all. My list was meant as a way for them to have a starting point for their justification of whatever they are going to do. I cannot say whether or not they want people to less-briefly summarize the previous discussions.
DPS statement -- Section 6.5 of the DPS for the root zone says that the KSK will be rolled over after five years of operation, and that time has already passed.
This connotes that the roll is over due, or about to be.
It states exactly the words in the DPS, and expresses a fact.
The wording is “after 5 years” and not “within 5 years.” I wasn’t part of this discussion, so perhaps there are those with a different memory than what is printed, but the words here tell me the “clock” in a roll starts after we have 5 years (and I’ll add “of experience running DNSSEC.”) So, I’d suggest changing to “5 years has lapsed” instead of “that time has already passed.”
Both statements are factually equivalent, unless you are looking for a connotation. I do not want this list to be slanted in any particular direction.
(Note, I would consider 6.5’s operation to begin in July 2010, a quibble, so we haven’t quite reached the 5 year horizon but we are certainly close enough to say we have. I note this to perhaps clear up when “operations” began - if we need to.)
That's an interesting angle that the panel could consider.
Cryptographic aging -- The longer a public key is known to an attacker, the longer the attacker has to determine the private key.
I would have thought “the longer and more often a public key is in use, the greater the chance cryptanalysis can be performed to discern the private key.”
That is a better wording, yes.
(And you could throw in that the more the key is put to use, the greater the chance it could be lost - hardware hits a bump and zeros - or it could be stolen - someone walks off with the healthy HSM.)
No one has suggested that before your message.
I think it’s helpful to separate the failure modes of keys (exposed/discovered, reverse engineered, lost, copied, stolen and whatever else) so we don’t "keep tripping over these cords.” My list probably duplicates scenarios.
Agree.
HSM aging -- The hardware signing modules (HSMs) used for the root key have a guaranteed life of five years, and that time has already passed.
I think this is a misstatement. I don’t want to confuse the story further so I won’t offer corrective text but encourage someone more familiar with the lifetime of components (particularly the batteries).
Richard is on it.
Operational practice for ICANN -- It is good to test the steps of a key rollover so that the holders of the key have practice; this helps prevent mistakes during future rollovers.
And prepares one for un-scheduled (emergency) changes.
That is subsumed in "future rollovers", yes?
Operational practice for operators -- It is good to test the steps of a getting new KSKs so that the users of the key have practice; this helps prevent mistakes during future KSK retrievals.
And prepares one for un-scheduled (emergency) changes.
That is subsumed in "future KSK retrievals", yes?
Change to ECDSA/P256 -- The ECDSA/P256 signing algorithm is both stronger than RSA/2048 and had better operational properties, and changing the KSK to use this will cause wider adoption throughout the DNSSEC community.
And, if I understand this correctly, smaller response sizes, a important facet for DNS. I haven’t confirmed this myself and hope that someone who has numbers can contribute to this.
The research has not yet been done, at least in public. --Paul Hoffman
On 2/23/2015 10:40 AM, Edward Lewis wrote:
HSM aging -- The hardware signing modules (HSMs) used for the root key
have a guaranteed life of five years, and that time has already passed. I think this is a misstatement. I don’t want to confuse the story further so I won’t offer corrective text but encourage someone more familiar with the lifetime of components (particularly the batteries).
This one is probably the most critical and the least understood of the reasons for doing a trust anchor update. The assumption you have to make is there is no way to move the private key from one HSM technology to another, and that there is no guarantee that the current HSM vendor will be in place to support their HSM for any given time. The reality may end up being different (e.g. there may actually be a way of extracting the private key from within the HSM policy boundary - which has its own issues, or the HSM vendor lives on for 20-30 years and is willing to support t), but we have to deal with the worst case scenarios. There are basically two sub issues for HSM aging: a) HSM support. This is basically what Paul wrote. Hardware has a finite lifetime. The HSM vendor guaranteed the current devices for 5 years and we're past that. Over the next 5 years we can expect failures in power supplies, chassis components and maybe even the core security processor. Failure of the former will require existence of replacement parts and service knowledge. Failure of the latter *MAY* result in the private key becoming unavailable. Redundancy is your friend here and having two of these is useful, but at some point we're going to have to migrate from the current generation of HSM to the next - either the same vendor or someone else - as support for the current devices becomes problematic. That migration is made simpler if we do not need to transfer the existing private key to the new technology. b) HSM vulnerability. The other problem with HSM aging is that security technology is always going to be an arms race. Breaking into a circa 2005 HSM design to extract the key is generally going to be easier in 2015. Moving to a new HSM designed to defeat new threats (e.g. various sensor and scanning technologies, fault injection, tamper detection defeats to prevent zeroization, etc) seems prudent every so often. Again, migration to new technology is simplified if we do not need to transfer the existing private key. So a new reason for trust anchor update: HSM key migration considered harmful. If you have to extradite a private key from one technology for injection in another - at some point the private key (encrypted or not) is vulnerable in the wild. There are ways to mitigate the vulnerabilities, but not to completely eliminate them. There are ways to generate a key pair and clone them safely (cryptographically safe, not just hardware safe) at the time of generation to multiple HSMs, but doing this after the fact requires updating the policy wrapping the signing key in a manner that could be attacked (e.g. you shouldn't be able to update the HSM code without wiping the keys).
On Mon, Feb 23, 2015 at 10:14 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
When considering how and when to rollover the root KSK, the community also have to consider why. In the past, many different reasons were given by various community members, and other community members have stated disagreements with some or all of those reasons. Thus, in order to make the how and when decision clearer to the community, the new KSK rollover panel needs to make explicit the reasoning for a particular rollover design.
The following are the most common reasons that have been given for why to roll over the root KSK. They are given using mildly positive language, and no counter-arguments are given. Each has a short-hand title to help facilitate the panel's thinking. If there are other reasons that someone in the community feels strongly about, it should be brought up so that the panel can consider it as well.
--Paul Hoffman
DPS statement -- Section 6.5 of the DPS for the root zone says that the KSK will be rolled over after five years of operation, and that time has already passed.
Cryptographic aging -- The longer a public key is known to an attacker, the longer the attacker has to determine the private key.
HSM aging -- The hardware signing modules (HSMs) used for the root key have a guaranteed life of five years, and that time has already passed.
Operational practice for ICANN -- It is good to test the steps of a key rollover so that the holders of the key have practice; this helps prevent mistakes during future rollovers.
Operational practice for operators -- It is good to test the steps of a getting new KSKs so that the users of the key have practice; this helps prevent mistakes during future KSK retrievals.
Change to ECDSA/P256 -- The ECDSA/P256 signing algorithm is both stronger than RSA/2048 and had better operational properties, and changing the KSK to use this will cause wider adoption throughout the DNSSEC community.
I'm not quite sure how to word this reason without is sounding overly broad, but "loss of faith" is the closest I can come up with - basically, for some reason (it doesn't really matter if it is a good one or not, rather it matters what people *believe*) the general public / users of DNSSEC lose faith in the security of KSK. An example scenario goes something like: ICANN fires Rick Lamb because he spills coffee on the CEO's tie. For obvious reasons this makes Rick *mad* and, on the way out the door he posts on a bunch of mailing lists and blogs "I know the private part of the KSK. It ends in 0x8675309." Various large news organizations pick up the story and it takes on a life of it's own. Numerous people spend weeks explaining that: A: Rick didn't know the number <insert complex bits about HSMs and recording of key ceremonies> B: There is no way to prove that, but, seriously... C: That's Jenny's number <points to https://www.youtube.com/watch?v=6WTdTwcmxyo > Of course, bringing technical arguments to a good conspiracy theory rant is like bringing a banana to a gunfight (https://www.youtube.com/watch?v=piWCBOsJr-w). Every time someone now mentions DNSSEC some nutter claims that this whole thing is broken because Rick knows the secret key and probably sold it to the mafia for cocaine and biscuits. At some point, if we want people to continue using DNSSEC we have to restore faith in the system by generating a new key (this time, in an even more public manner). W
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
participants (9)
-
Ashley Heineman -
David Conrad -
Edward Lewis -
Jacques Latour -
Kumar Ashutosh -
Michael StJohns -
Paul Hoffman -
Richard Lamb -
Warren Kumari