Subject: [dnsop] DOP #5: Key sizes and Effectivity Period

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 13 Jun 2005 14:51:34 +0200

Also see thread starting at:
   http://darkwing.uoregon.edu/~llynch/dnsop/msg03465.html

 In a discussion between Olaf and Ed, Ed was the last to reply: 
>
> >>
> >>  #3.3  Key Effectivity Period
> >>
> >>  #   For Key Signing Keys a reasonable key effectivity period 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.
> >>
> >>  Shouldn't this be linked to some minimum size of the key?
> >>
> >
> >
> >What about prepending a line to the above paragraph introducing a new
> >one sentence paragraph directly after that:
> >
> >+  From a purely operational perspective a reasonable key effectivity
> >+  period for Key Signing Keys 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.
> >
> >+  For a key-size that matches these effectivity periods see section 3.5
> >
> >    Using these recommendations will lead to rollovers occurring
> >    frequently enough to become part of 'operational habits'; the
> >    procedure does not have to be reinvented every time a key is
> >    replaced.
> >
> >    Key effectivity periods can be made very short, as in the order of a
> >    few minutes.  But when replacing keys one has to take the
> >    considerations from Section 4.1 and Section 4.2 into account.
> 
> I have two answers to this.
> 
> One is that I think recommending a span of changes is good, and 
> saying that you should fit the key size to the span.  (As opposed to 
> trying to worry about how long a key of a certain size will last.) 
> Operations can deal with the calendar better than less tangible 
> "events" (such as the time until a key is exposed or guessed).
> 
> The other answer is that I have heard suggestions that the KSK ought 
> to be longer lived - like 3 or so years.  For the root, because of 
> the pain of putting it into anchor positions, even longer.  This is 
> counter to "keep it regular so you get used to it" but it has appeal 
> to non-operations people.
> 
> I think it would be wise to recommend timing because there aren't a 
> lot of clear statements on this important issue.  But perhaps you 
> need to recommend different time scales for different kinds of zone 
> administrations.
> 
> Others?
> 

Also see Bill Mannings reply:
   http://darkwing.uoregon.edu/~llynch/dnsop/msg03469.html

I read Ed's first answer as concurring with the text.

I read Ed's second answer as a request for more text. I wonder if that
request still stands if we put this text back into section 3.3 and
view it in its context. Section 3.1 starts with the some special
remarks about the high level zones and trust anchor difficulties.

I would like to propose to keep the text as is propose above (in the
paragraphs with the "+" signs. But extend it with a reference to 3.1.2
(the ++ signs)

+  From a purely operational perspective a reasonable key effectivity
+  period for Key Signing Keys 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.

+  For a key-size that matches these effectivity periods see section 3.5

    Using these recommendations will lead to rollovers occurring
    frequently enough to become part of 'operational habits'; the
    procedure does not have to be reinvented every time a key is
    replaced.

++  As argued in 3.1.2 securely updating trust-anchors will be extremely 
++  difficult. On the other hand the "operational habit" argument does
++  also apply to trust-anchor reconfiguration. If a short key-effectivity  
++  period is used and the trust-anchor configuration has to be revisited 
++  on a regular basis the odds that the configuration tends to be
++  forgotten is smaller. The tradeoff is against a system that is so dynamic
++  that administrators of the validating clients will not be able to
++  follow the modifications. 

    Key effectivity periods can be made very short, as in the order of a
    few minutes.  But when replacing keys one has to take the
    considerations from Section 4.1 and Section 4.2 into account.

I am hesitant to come up with different time scales for different zone
adminsistrators. I would also like to remind folk that this document
is intended as guidance for "common domain operators".

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Ben Laurie <[email-masked]>
Date: Wed, 15 Jun 2005 10:55:42 +0100

> is intended as guidance for "common domain operators".

One thing that hasn't been noted, as far as I can see, is that there's 
not much point having a key longer than your parent's key.

Or, to turn it on its head, if you want to use a key of size K, then you 
should make sure your parent signs it with a key of size K or larger.

Cheers,

Ben.

-- 
 >>>ApacheCon Europe<<<                   http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 15 Jun 2005 12:26:07 +0200

On Wed, 15 Jun 2005 10:55:42 +0100

> not much point having a key longer than your parent's key.

Good catch... Thanks

> should make sure your parent signs it with a key of size K or larger.

The exception here would be the folk that also use this key as a
trust-anchor locally. Then local policy may want to dictate a longer
key than the parents.

-- Olaf

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 20 Jun 2005 10:42:41 +0200

On Wed, 15 Jun 2005 12:26:07 +0200

> > not much point having a key longer than your parent's key.

I thought about this a little more but I am not sure what you said
holds.

You can have a longer key than your parent's zone if has made a
different tradeoff between length and key-effectivity period than
yourself. E.g. your parent uses a 1000 bits key for 2 months and you
use a 2048bit key for 3 years.

Besides it may be that your local policy dictates that you verify your
own domains with locally configured trust anchors that may consist out
of more bits than the weakest link validation chain.

correct?

-- Olaf

---

From: Ben Laurie <[email-masked]>
Date: Tue, 21 Jun 2005 13:11:39 +0100

> use a 2048bit key for 3 years.

Its true that there's a complication introduced by key effectivity 
period. But given that the most efficient factoring algorithms take time 
O(e^2(ln(q)ln(ln(q)))^.5) (where q is the number to be factored), for 
practical key sizes, this means that doubling the keysize causes such an 
astronomical increase in work factor (e.g. 2048 bits takes 10^29 times 
as long as 1024 bits) that you may as well ignore the trivial difference 
the effectivity period makes.

Or, to turn it on its head, to have a key that would take twice the time 
to crack as a 1024 bit key, use 1033 bits.

> of more bits than the weakest link validation chain.

This is indeed true, but an orthogonal point.

Cheers,

Ben.

--