<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2/23/2015 11:18 AM, Richard Lamb
wrote:<br>
</div>
<blockquote
cite="mid:1617c61acf5e415e87dc779aff31ff66@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG"
type="cite">
<pre wrap="">Oops...attachment</pre>
</blockquote>
<br>
For me, I'm not all that worried about batteries unless the design
of this thing is way different that other HSMs.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Later, Mike<br>
<br>
<blockquote
cite="mid:1617c61acf5e415e87dc779aff31ff66@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG"
type="cite">
<pre wrap="">
-----Original Message-----
From: Richard Lamb
Sent: Monday, February 23, 2015 5:17 PM
To: Edward Lewis; Paul Hoffman; <a class="moz-txt-link-abbreviated" href="mailto:ksk-rollover@icann.org">ksk-rollover@icann.org</a>
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: <a class="moz-txt-link-abbreviated" href="mailto:ksk-rollover-bounces@icann.org">ksk-rollover-bounces@icann.org</a> [<a class="moz-txt-link-freetext" href="mailto:ksk-rollover-bounces@icann.org">mailto:ksk-rollover-bounces@icann.org</a>] On Behalf Of Edward Lewis
Sent: Monday, February 23, 2015 4:40 PM
To: Paul Hoffman; <a class="moz-txt-link-abbreviated" href="mailto:ksk-rollover@icann.org">ksk-rollover@icann.org</a>
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" <a class="moz-txt-link-rfc2396E" href="mailto:paul.hoffman@vpnc.org"><paul.hoffman@vpnc.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.)
</pre>
<blockquote type="cite">
<pre wrap="">Cryptographic aging -- The longer a public key is known to an attacker,
the longer the attacker has to determine the private key.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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).
</pre>
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
And prepares one for un-scheduled (emergency) changes.
</pre>
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
And prepares one for un-scheduled (emergency) changes.
</pre>
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
ksk-rollover mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ksk-rollover@icann.org">ksk-rollover@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/ksk-rollover">https://mm.icann.org/mailman/listinfo/ksk-rollover</a>
</pre>
</blockquote>
<br>
</body>
</html>