[ksk-change] Helping the panel name the reasons for the KSK rollover

Paul Hoffman paul.hoffman at vpnc.org
Mon Feb 23 16:53:59 UTC 2015


On Feb 23, 2015, at 7:40 AM, Edward Lewis <edward.lewis at 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


More information about the ksk-rollover mailing list