Subject: [DNSOP] rfc4641bis: ZSK-roll-frequency

From: Olaf Kolkman <[email-masked]>
Date: Thu, 21 Jan 2010 14:28:36 +0100

As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has the open issues listed and a per issue highlight of their history.

This issue is captured in  
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency
current content of that page is replicated below.

I welcome substantive discussion on-list while I'd be happy to receive editorial comments off-list 

If the chair believes the current text captures consensus I will move this issue to the closed issues list.

--Olaf

$Id: ZSK-roll-frequency 31 2009-10-07 08:19:53Z olaf $
2008090101
   ZSK-roll-frequency
   EKR/ Paul Hoffman
   Added: 7 Oct 2009
   
See:
http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html

Rfc4641 argues for frequent ZSK rollovers, the argument therein is
based on operational arguments that are (implicitly) based on operator
acces to private keys and/or the timeline in which changes in which
the (zone) operator may need to be replaced.

EKRs argument is based on cryptographic strength and argues another view.

The current considerations need to be made more explicit.

Resolution:

Added the following paragraph to section 3.3:

	<t>
	  The motivation for having the ZSK's effectivity period
	  shorter than the KSK's effectivity period is rooted in the
	  operational consideration that it is more likely that
	  operators have more frequent read access to the ZSK than to
	  the KSK. If ZSK's are maintained on cryptographic Hardware
	  Security Modules (HSM) than the motivation to have different
	  key effectivity periods is weakend.

	</t>

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Jan 2010 05:34:18 -0800

I'm not really an active member of the WG, so I certainly wouldn't say that
my position has much of an affect on consensus, but I'm unconvinced
by the argument offered below.

Sure, the ZSK is at greater risk because operators have access to it, but
so what? If an operator actually steals the key (or, say, is fired), you
change the key then. However, given that you allow the operator to sign
stuff with the key as long as he's employed, I don't see how repeatedly
changing it during that period offers much value at all.

-Ekr

On Thu, Jan 21, 2010 at 5:28 AM, Olaf Kolkman <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: "Rose, Scott W." <[email-masked]>
Date: Thu, 21 Jan 2010 09:09:50 -0500

Perhaps the wording is a bit incorrect in that it an insider attack (the
admin accessing the key) is not the biggest threat.  The ZSK is accessed
more often and if it isn't on an HSM (or similar), there could be a risk
that it could be exposed by someone other than the responsible DNS admin. Of
course the use of an HSM minimizes this risk.

How about this as suggested text?

<t>
        The motivation for having the ZSK's effectivity period
        shorter than the KSK's effectivity period is rooted in the
        operational consideration that the ZSK may be at more
        risk of exposure as the ZSK is often used more frequently
        (e.g. zone data updates, etc.). If ZSK's are maintained on
        cryptographic Hardware Security Modules (HSM) than the
        motivation to have different key effectivity periods is
        weakend.
</t>

Scott
On 1/21/10 8:34 AM, "Eric Rescorla" <[email-masked]> wrote:

>> As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has
>> the open issues listed and a per issue highlight of their history.
>> 

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
Google Voice: +1-571-249-3671

http://www.dnsops.gov/
===================================

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 21 Jan 2010 16:06:06 +0100

>        motivation to have different key effectivity periods is

I understand EKR's remark (thanks) in addition to the improvement Scott suggested there is the argument that if a rollover remains a special event it is bound to go wrong, while if it is part of regular operational procedure the operators do not have to go through the learning curve. That argument works, but not in the case that EKR brought up, if _the_ operator gets sacked the rollover done by the new one is the first one that new operator does, she wouldn't have the benefit of operational routine.

--Olaf
[nothing below, only context]

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Jan 2010 10:14:41 -0500

IMHO, the suggested wording is backwards.

It's not that the ZSK effectivity period is shorter than the KSK's, 
the KSK effectivity period is longer than the ZSK's.  The reason is 
operational, not cryptographic.

Way back in time (circa '99-'02)...consensus of those participating 
in workshops was that it was wise to change the ZSK a lot but we 
found it to be a pain to have to wait to tell the workshop 
coordinator/registry operator to get them to update the key in the 
workshop zone.  So we invented the idea of ZSK/KSK.  We just wanted 
to have a KSK that lasted longer than a ZSK.

We rationalized that a KSK would last longer because 1) it generated 
only a few signatures over the same time period compared to a ZSK, 2) 
because it was only needed when the key set changed, it was open to 
the air less frequently, and 3) since it was used only to validate 
the key set, it could be longer (thus taking longer to do the 
signature validation) but not needed in every validation (of records 
in a particular zone).  Because it was longer lasting we didn't have 
to stop and get the attention of the parent so frequently.

(Reason 3 is why so many TLDs now have the KSK twice as long as the ZSK.)

I'm not saying that any of the above was smart wrt cryptography - 
crypto-experts never made any statements to us back then.  The KSK 
being longer than the ZSK was for operational convenience.

Also, what was not anticipated was the coming of automated 
provisioning, like that enabled by EPP, in reducing the latency of 
getting the parent to make a change.  (Around 2000, we envisioned 
parent zone updates on the order of 1/day or n/week, not every 15 
minutes.)  At the time too - HSMs didn't exist in our world, and we 
still thought that all signing would be done on a machine with an 
air-gap to the Internet.

So many assumptions have changed...but the idea of KSK/ZSK hasn't.

If I were to fit this into the text below...

#<t>
#        The motivation for having the KSK's effectivity period
#        longer than the ZSK's effectivity period is rooted in the
#        operational consideration that a change in the KSK involves
#        interaction with an external entity, usually the parent zone
#        or possibly a trust anchor repository, and this interaction
#        is anticipated to have significant latency (including the
#        need to verify the other party has made the necessary change.
#</t>

At 9:09 -0500 1/21/10, Rose, Scott W. wrote:
>>>  As a reminder: 
>>>http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Jan 2010 10:39:29 -0500

> So many assumptions have changed...but the idea of KSK/ZSK hasn't.

Maybe this is the problem?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Jan 2010 10:48:52 -0500

>Maybe this is the problem?

Problem?

Not everyone has an automated registration interface (making that a 
reason to have a KSK/ZSK still hold).

And the key word above is "assumptions" - once we know for a fact 
that a ZSK of 1024 bits is good for a year no matter how much it is 
used and that it's okay to roll it, etc., then we might be able to 
drop the KSK idea.  So long as it hasn't  already been burned into 
operational (institutional) practices.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Jan 2010 11:02:23 -0500

>> Maybe this is the problem?

It that it seems to be the occasion of a lot of disagreement with the
document.  That is, in many cases, perhaps the advice should simply
be, "The ZSK/KSK split is useful in some circumstances, but for most
applications one key is sufficient."  Or some such.  I'm not proposing
this text, I'm asking.

> reason to have a KSK/ZSK still hold).

Sure, but this may well be the exception and not the rule.

> And the key word above is "assumptions" - once we know for a fact that a 
> ZSK of 1024 bits is good for a year no matter how much it is used and 

Nobody can ever know that for a fact, because it would require proving
impossible that such a key could be cracked.  Predictions of future
impossibility are hard to prove.  This is a question of trade-off, not
facts, and one of the questions is the degree to which two keys
themselves introduce risks that aren't offset by the gains they might
produce.  I simply don't know the answer, but it seems to me that EKR
is asking the right question.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Jan 2010 11:14:25 -0500

>Sure, but this may well be the exception and not the rule.

And I've heard the opposite.  "automated-registry[0]"-run zones are 
in the minority.  (I.e., second level domains, third-level domains, 
etc...)

[0] Not just EPP-using-registries.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: "Rose, Scott W." <[email-masked]>
Date: Thu, 21 Jan 2010 11:20:04 -0500

> reason to have a KSK/ZSK still hold).

And experience has shown that different assumptions of how best to automate
things also cause problems.  So one side may be reduced to doing things
manually (and usually it's the registrant) when the registrant and registrar
used different implementations.

On the larger issue - It may be easier to say "The KSK is larger/longer
lived than the ZSK because..." than "The ZSK is smaller/shorter lived than
the KSK because..." and give the reasons.

Scott 

--

http://www.dnsops.gov/

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Jan 2010 11:24:04 -0500

On Thu, Jan 21, 2010 at 11:14:25AM -0500, Edward Lewis wrote:
> And I've heard the opposite.  "automated-registry[0]"-run zones are in 
> the minority.  (I.e., second level domains, third-level domains, etc...)

Sure.  I think the problem here is that we don't know.  I have no clue
how many systems are updated exclusively by Dynamic Update vs. by
someone opening the zonefile in vi.  I don't think anyone else knows,
either: the scope of DNS operations is far too widely dispersed for
anyone to have done anything like a survey.  Therefore, the best we
can do is recomment the techniques appropriate to different
circumstances.

It seems to me that one such technique is, "If it's easier for you to
transmit a new DS/DNSKEY than it is for you to roll a KSK, then you
don't need a separate KSK.  Just roll the one key and be done with
it."

A separate question, then, is whether the operational regularity that
comes from exercising the above technique all the time outweighs the
risks associated with frequent key rolls that result from getting the
timing wrong.  (My personal opinion is a cautious "yes", but I don't
know how firmly I hold that view.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Tony Finch <[email-masked]>
Date: Thu, 21 Jan 2010 16:28:14 +0000

On Thu, 21 Jan 2010, Olaf Kolkman wrote:
>
> I understand EKR's remark (thanks) in addition to the improvement Scott
> suggested there is the argument that if a rollover remains a special
> event it is bound to go wrong, while if it is part of regular
> operational procedure the operators do not have to go through the
> learning curve. That argument works, but not in the case that EKR
> brought up, if _the_ operator gets sacked the rollover done by the new
> one is the first one that new operator does, she wouldn't have the
> benefit of operational routine.

Operational routines like this will be automated.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Jan 2010 11:40:00 -0500

> Operational routines like this will be automated.

I wish I believed that was universally true.  It isn't.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 21 Jan 2010 08:55:33 -0800

At 11:02 AM -0500 1/21/10, Andrew Sullivan wrote:
>impossibility are hard to prove. 

But we *can* assume that there are a lot of 1024-bit keys in use that are much more valuable than the most valuable DNSSEC 1024-bit key. Thus, as public analysis gets better, we are likely to hear about it. Even if the first attacks from private crackers, we will hear about them.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Jan 2010 11:58:05 -0500

On Thu, Jan 21, 2010 at 08:55:33AM -0800, Paul Hoffman wrote:
> 
> But we *can* assume that there are a lot of 1024-bit keys in use
> that are much more valuable than the most valuable DNSSEC 1024-bit
> key. Thus, as public analysis gets better, we are likely to hear
> about it. Even if the first attacks from private crackers, we will
> hear about them.

I fully agree.  I just want to make sure we're not holding ourselves
to an operational standard that is just impossible to reach.  If we
want "proof" and "facts" about whether something won't ever be
compromised, it's not going to happen (so I'm very keen we not put
anything resembling such language in any draft).  That's all I was
saying.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 21 Jan 2010 13:03:45 -0500 (EST)

> #        need to verify the other party has made the necessary change.

Maybe make it more explicit that an intra-organisation key change can
and probably should happen frequently, where-as an inter-organisational
key change, because it involves other organisations, is more difficult
and should be kept to a minimum?

Again, think of a zone administrator who had access to a private ZSK
leaving your organisation. It would be a good security policy to rollover
the ZSK as part of the procedure of revoking this person's access to
the organisation. And a good reason to have an HSM so you do not need
to do the same with the KSK.

Paul

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Jan 2010 13:40:03 -0500

>and should be kept to a minimum?

Well, "the motivation" in the historical sense is what I had in mind 
when writing, as opposed to "the motivation" in the sense of the 
reason for something.

>to do the same with the KSK.

I don't get the last sentence of what you wrote.

The trouble is, there's no good general statement that can be made 
here.  There are cases in which I would say an HSM is a good thing 
and there are cases where it is merely window dressing.  In places 
where one might think it is essential are the very places where it 
might be most optional.

If we don't have a HSM and someone who had access to the key leaves, 
it's not hard for us to (in the future) contact IANA and change our 
key.  While the HSM might prevent any employee's leaving from being a 
threat, the defense against the threat is cheap (an email/phone 
call/whatever to IANA).

I'm not trying to find excuses for avoiding an HSM.  Just pointing 
out why I can't endorse them as functional necessities.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Jan 2010 11:05:47 -0800

I still don't understand why this implies the need for regular changes
as opposed
to changes triggered by personnel changes.

-Ekr

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Jan 2010 14:17:58 -0500

At 11:05 -0800 1/21/10, Eric Rescorla wrote:
>as opposed to changes triggered by personnel changes.

I'm a bit lost following this thread now.

For the time being, let's ignore personnel changes and whether a key 
is in an HSM (environment), i.e., assume there's no organizational 
threat to a key.

The question is, how long does a key last?

Meaning - if I am using an RSA-SHA256 key of 1024 bits, at what point 
does it's security value reach essentially 0?

Is the point X number of signatures?

Is the point Y number of days?

Is the point a function of X and Y?

Is there even a point at all?

Even now, more than 10 years after the first SE workshop, I have 
never heard an expert or authority on cryptography give neither a 
concrete answer nor direction on this.  While I realize the answer 
isn't as simple as "after 43,253 signatures" or "after 1348 days", I 
haven't heard anything that could be used as guidance in an 
operational setting.

The "need for regular changes" stems from assumptions made in the 
early days of DNSSEC development that have gone pretty much 
unchallenged until recently.  The door is open to (re)visit this 
topic, if anyone wants to venture opinions.

What I'd like to hear is:

"Crypto-expert __________ says an RSA-SHA256 key of 1024 bits is good 
for _______ signatures/days."

That's what I'd like for my birthday present this year.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 21 Jan 2010 11:38:43 -0800

At 2:17 PM -0500 1/21/10, Edward Lewis wrote:
>For the time being, let's ignore personnel changes and whether a key is in an HSM (environment), i.e., assume there's no organizational threat to a key.
>
>Meaning - if I am using an RSA-SHA256 key of 1024 bits, at what point does it's security value reach essentially 0?
>

No. There is no suspicion on the part of any cryptographer that I know of that the number of visible signatures is significant for a 1024-bit or above key.

>Is the point Y number of days?

Yes, if the number of days is in the thousands (currently) and the value of this key is high. Otherwise, no.

>Is the point a function of X and Y?

No, just Y.

>Is there even a point at all?

For most keys, no, at least for the next five years or so. That is, the *cost* of breaking a 1024-bit key, when that is feasible, is still much higher than the value of the broken key. Remember that a broken signing key is only valuable until the fact that it is broken is discovered and fixed. So, even if an attacker breaks your signing key, when he/she starts to use it for nefarious purposes and you discover that, you roll your key and the entire time of breaking the new key must be used again before they can mount another attack.

>Even now, more than 10 years after the first SE workshop, I have never heard an expert or authority on cryptography give neither a concrete answer nor direction on this.

I have tried, repeatedly, to do so, but I am not an expert, nor apparently enough of an authority for you. Ekr is both; let's see if he likes my response above.

>  While I realize the answer isn't as simple as "after 43,253 signatures" or "after 1348 days", I haven't heard anything that could be used as guidance in an operational setting.

See above.

>The "need for regular changes" stems from assumptions made in the early days of DNSSEC development that have gone pretty much unchallenged until recently.  The door is open to (re)visit this topic, if anyone wants to venture opinions.

See above. :-)

>"Crypto-expert __________ says an RSA-SHA256 key of 1024 bits is good for _______ signatures/days."

If you hear that, the the value for the first variable will be worthless. You have to factor in the value of the key to the attacker for the short period in which they can use it before their actions are discovered and the broken key is replaced.

>That's what I'd like for my birthday present this year.

You're better off wishing for a pony.

--Paul Hoffman, Director
--VPN Consortium

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 21 Jan 2010 20:49:55 +0100

> Operational routines like this will be automated.

That is what I would hope. But documents like this do suggest the defaults and EKRs arguments for 'ad-hoc' rolling or the other comments for regular rolling do impact the market that provides the automation.

-- Olaf

(Full disclosure: NLnet Labs is part of a group that develops this sort of software, opendnssec).

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Jan 2010 14:49:11 -0500

>I have tried, repeatedly, to do so, but I am not an expert, nor apparently
>enough of an authority for you. Ekr is both; let's see if he likes my
>response above.

Just to remove any thought that I intended to slight anyone - I must 
have missed whatever you had said before.

;)

>You're better off wishing for a pony.

I thought so.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Jan 2010 12:12:50 -0800

> No. There is no suspicion on the part of any cryptographer that I know of that the number of visible signatures is significant for a 1024-bit or above key.

Agreed. Recall that with PKC an attacker can generate as many
plaintext/ciphertext pairs as
he wants.

> Yes, if the number of days is in the thousands (currently) and the value of this key is high. Otherwise, no.

I actually sort of disagree with this. I don't see how to evaluate
this question in a meaningful
way, and it's not a cryptographic question. Let's say for the sake of
argument that we know
if requires C CPU-hours to break a key and that each CPU costs $H but
is free to run once
you own it (not true). In that case, an attacker with $D to spend can
break a single key in
C/(D/H) hours.  How long is that key secure for? Who knows. Most of
the variance is in attacker
motivation and funding, not time.

> For most keys, no, at least for the next five years or so. That is, the *cost* of breaking a 1024-bit key, when that is feasible, is still much higher than the value of the broken key. Remember tha…

Exactly. So rolling it preemptively doesn't help much.

-Ekr

>>The "need for regular changes" stems from assumptions made in the early days of DNSSEC development that have gone pretty much unchallenged until recently.  The door is open to (re)visit this topic,…

So, the referenced post summarizes my opinion. I don't care enough about it to
fight it to the death here, however.

> If you hear that, the the value for the first variable will be worthless. You have to factor in the value of the key to the attacker for the short period in which they can use it before their actio…

I more or less agree with this. You may want to hear that, but there's
no meaningful answer.

-Ekr

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Jan 2010 05:18:14 +0900

Edward Lewis wrote:

> Also, what was not anticipated was the coming of automated provisioning, 

Yes, it was anticipated.

It was obvious from the beginning of DNSSEC that automated provisioning
operationally unavoidable.

> At the time too - 
> HSMs didn't exist in our world, and we still thought that all signing 
> would be done on a machine with an air-gap to the Internet.

In draft-ohta-simple-dns-00.txt (August 1994), it is already written

   In
   cases where frequent and/or automatic update of a zone is desired, it
   is necessary to make signature generation mechanism of the zone
   accessible on-line.  Still, it is worthwhile to keep the secret
   information and secure time stamping mechanism of the zone off-line.

HSM was also considered but was not essential, because secret keys of
signature genration mechanisms may be physically protected in various
ways.

> So many assumptions have changed...but the idea of KSK/ZSK hasn't.

It is merely that your assumptions including that on KSK/ZSK have
been bogus.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Jan 2010 05:25:29 +0900

Andrew Sullivan wrote:

> compromised,

Remember that DNSSEC was developed because it was believed to make
DNS proven to be secure.

> it's not going to happen (so I'm very keen we not put

You are saying DNSSEC is *NOT* cryptographically secure.

You are saying DNSSEC merely operationally secure.

And, you are right.

That is, there is no point of deploying DNSSEC.

						Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Jan 2010 15:27:45 -0500

> > is still much higher than the value of the broken key. Remember
> > that a broken signing key is only valuable until the fact that it
> > is broken is discovered and fixed. So, even if an attacker breaks
> > your signing key, when he/she starts to use it for nefarious
> > purposes and you discover that, you roll your key and the entire
> > time of breaking the new key must be used again before they can
> > mount another attack.
> 

What about the argument that you might not discover the nefarious use
(because a small number of DNS transactions, carefully selected, are
the only misdirected ones, and everything else appears normal, so you
chalk it up to user error)?  Remember that unlike many cryptographic
protocols, there's no real end-to-end communication here.  It could
well be hard for a key owner to detect the compromise in a DNS context
than in many other contexts. 

If one accepts that argument (I don't know I do, but let's accept it
for the sake of argument), then rolling regularly (modulo jitter)
could be argued for on the grounds that it will cut off even
undetected compromises.  

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Jan 2010 15:40:02 -0500

> Remember that DNSSEC was developed because it was believed to make

You're equivocating on "proof" or "secure" or maybe both.

DNSSEC allows you to prove that, assuming secure keys, you're getting
the the correct (i.e. authoritatively-sourced) answer.

It does not allow you to prove that the keys were handled properly,
that Dr Evil hasn't taken over the authoritative machine, that we
really are living in a Euclidean universe with the relevant
mathematical structures, or that ChipManufactureCorp didn't have a
serious bug that caused every cryptographic operation it ever does to
be predictable.  It also doesn't allow you to prove that Bishop
Berkeley's metaphysics was wrong, such that you are in fact connecting
to a computer somewhere out there in the world and not just a
representation-of-foreign-computer in your consciousness.

No other cryptographic proof can ever prove such things, either, since
a cryptographic system invariably involves those nasty graphos, who
are prone to making errors.  Moreover, no existing system can prove
that there is not an undiscovered vulnerability of an algorithm
(though I understand there are proofs that, under known mathematical
assumptions, some algorithms cannot be broken.  That's not the same
thing).  If you wish otherwise, I think you are asking that Godel be
proven wrong.  

If you dislike the word "prove" and cognates to be used for anything
other than mathematical certainty, then I suggest you translate any
use of "proof" that involves parts of the physical universe into some
other term like "increased confidence in the empirico-statistical
sense".

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 21 Jan 2010 12:54:34 -0800

>could be argued for on the grounds that it will cut off even

...as long as there is no cost to rolling regularly. But there are many:

- A botched roll can cause validating resolvers to not trust any of your answers

- A botched roll can (I think) cause your zone to go bogus

- Regular rolling can give you a false sense of security about your rolling process

These are about as intangible as the cost of an attacker using a compromised key until you discover and change the key. Thus, you want to make the cost to the attacker as high as possible. The easiest way to do that is a longer key, such as 2048 bits, or a better signing algorithm, such as ECDSA.

--Paul Hoffman, Director
--VPN Consortium

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Jan 2010 06:09:23 +0900

> the the correct (i.e. authoritatively-sourced) answer.

As a person who have been working on DNS before early days of DNSSEC,
I remember very well why DNSSEC was developed.

As is written in RFC2065:

   Careful key generation is a sometimes overlooked but absolutely
   essential element in any cryptographically secure system.

That is, DNSSEC was wrongly believed to be cryptographically secure.

> If you dislike the word "prove" and cognates to be used for anything

"cryptographically secure" is fatal enough.

						Masataka Ohta

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Jan 2010 16:14:03 -0500

>...as long as there is no cost to rolling regularly. But there are many:

I'm finding this discussion enlightening and interesting.

If the logic is that the only need to roll is event-based (detecting 
a violation) because there is risk of a roll going badly - then 
there's a reason to regularly "drill" when there's no threat to make 
sure you minimize the chance of a screw-up during a real emergency.

How ironic. ;)

What scares me (too) is Andrew's observation that you might fail to 
detect a bad key because of the size of a zone and potentially a 
targeted attack on just one or two domains.

Perhaps monthly rolls aren't needed for crypto-sake, but the more 
apparent this is the more apparent we need regular rolls for 
operations-sake.

A bad roll will be detected and fixed faster than a secretly broken 
key and an isolated target.

---

From: David Conrad <[email-masked]>
Date: Thu, 21 Jan 2010 13:19:31 -0800

On Jan 21, 2010, at 1:14 PM, Edward Lewis wrote:
> Perhaps monthly rolls aren't needed for crypto-sake, but the more apparent this is the more apparent we need regular rolls for operations-sake.

Thanks.

While I might agree that _theoretically_ longer keys and/or better algorithms removes or at least reduces the need to do frequent roles, the operational reality empirically proven in a variety of fields is that if you don't exercise stuff, it is going to break when you need it.

Regards,
-drc

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Jan 2010 13:26:28 -0800

Again, I don't feel strongly about this, but I don't really find this
very convincing.

Presumably there are all sorts of other credentials that control access to the
ZSK (e.g., administrator SSH private keys, root passwords, etc.) Do you also
propose to roll all of these every month? If not, why not?

-Ekr

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Jan 2010 16:29:38 -0500

> I'm finding this discussion enlightening and interesting.

Me too.  I also think that discussion of exactly this sort belongs in
the advice we give to operators.  Understanding the trade-offs and the
reason for them is exactly what makes for selecting the right policies
given the operational considerations of the environment in which one
is working.  I don't think there's one answer for this question,
because what is right is surely related to other considerations.

For instance, despite what David says downthread about operational
realities and exercise, such exercise is a complete waste of time if
the person who does the work is different every time (as might well be
the case under a lot of outsourcing contracts).  In that circumstance,
Paul is probably right: the risk of blowing the key roll outweighs the
benefits of practice.

One also worries a little that many operations people (me included) so
often think "you need to practice this" includes "in production".
(But I haven't worked many places where I've had a real, true,
complete copy of my production systems just for running fire drills.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Jan 2010 16:42:46 -0500

As a matter of fact, a lot of the security credentials (SSH keys, 
passwords, etc.) are rolled on a regular basis already, as part of 
institutional security policies.

But I think a point has been missed - the roll of keys on a periodic 
basis is needed to *exercise the activity* if not achieve a higher 
level of security.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Jan 2010 16:45:12 -0500

>complete copy of my production systems just for running fire drills.)

But where else (besides production) can you also test that ISPs get 
the right key into their verifiers?  The Internet is an 
interconnected mesh of entities, no walled garden is an island...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: David Conrad <[email-masked]>
Date: Thu, 21 Jan 2010 13:47:56 -0800

>> propose to roll all of these every month? If not, why not?
...
> But I think a point has been missed - the roll of keys on a periodic basis is needed to *exercise the activity* if not achieve a higher level of security.

+1

Fixing secretly compromised ZSKs is a side benefit.

Regards,
-drc

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 21 Jan 2010 13:48:17 -0800

At 4:14 PM -0500 1/21/10, Edward Lewis wrote:
>If the logic is that the only need to roll is event-based (detecting a violation) because there is risk of a roll going badly - then there's a reason to regularly "drill" when there's no threat to make sure you minimize the chance of a screw-up during a real emergency.
>
>How ironic. ;)

Yep. It is also ironic (and iconic) that the DNSSEC community is just now discovering the operational tradeoffs that the security industry has known for well over a decade.

>What scares me (too) is Andrew's observation that you might fail to detect a bad key because of the size of a zone and potentially a targeted attack on just one or two domains.

What he is saying is the same thing that Eric and I said: you *have* to factor in the value to the attacker of using the compromised key versus the risk that being caught using it will force him to have to re-do all his work.

>Perhaps monthly rolls aren't needed for crypto-sake, but the more apparent this is the more apparent we need regular rolls for operations-sake.

Why do you equate "regular" with "monthly"? And why do they have to be "regular"? A perfectly valid operational goal would be "whenever there is enough new staff who should see how we do a roll, plus once and a while during a period where, if we botch it, there is the least amount of damage and the best opportunity to fix it". For VeriSign, that might translate to "monthly", but for ImportantCompany.com, it might translate to "once a year or so".

>A bad roll will be detected and fixed faster than a secretly broken key and an isolated target.

Sure, but "time" is the wrong unit of measure: "cost" is. The reputation cost for a botched roll could be much, much higher than a small number of believed answers to an "isolated target".

>propose to roll all of these every month? If not, why not?

Bingo.

--Paul Hoffman, Director
--VPN Consortium

---

From: David Conrad <[email-masked]>
Date: Thu, 21 Jan 2010 13:57:49 -0800

Andrew,

On Jan 21, 2010, at 1:29 PM, Andrew Sullivan wrote:
> the case under a lot of outsourcing contracts).

Err, no.  The exercises would not be a waste of time.

First time a scheduled roll botches, any rational organization would institute policies and processes to ensure that such a botch does not reoccur.  First time a scheduled roll botches with a new outsourced contractor, any rational organization would institute policies and processes to ensure that such a botch does not reoccur.  Etc.

There is a reason people have "fire drills" on a periodic schedule.  Folks really concerned about operational readiness also have those drills on unannounced schedules.

As Ed points out, the issues here are confused because of the assumption that it is done for crypto security.  The crypto stuff is (in my mind) a side benefit.

Regards,
-drc

---

From: Roy Arends <[email-masked]>
Date: Thu, 21 Jan 2010 17:11:13 -0500

On Jan 21, 2010, at 4:42 PM, Edward Lewis wrote:

> As a matter of fact, a lot of the security credentials (SSH keys, passwords, etc.) are rolled on a regular basis already, as part of institutional security policies.
> 

I'd recommend that 'exercise the activity' is not done on critical production systems.

Roy

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Jan 2010 17:20:20 -0500

On Thu, Jan 21, 2010 at 01:57:49PM -0800, David Conrad wrote:
> 
> First time a scheduled roll botches, any rational organization would
> institute policies and processes to ensure that such a botch does
> not reoccur.  First time a scheduled roll botches with a new
> outsourced contractor, any rational organization would institute
> policies and processes to ensure that such a botch does not reoccur.

You have worked in more enlightened organizations than I, then.

In my experience, with a lot of this sort of outsourcing, what will
happen is that the outsourcing company will produce an incident report
detailing the many ways the overworked drone who didn't know what he
was doing screwed up, why their JD Power or whatever surveys prove
that this never happens to them, and the 40 meetings that will be held
to ensure that even though this was in fact an impossible event, it
will never happen again.

In an organization that actually knows what it is doing
technologically, I'm sure you're right.  In an organization that
doesn't actually care about running its systems because everyone there
has something else they're really doing, DNSSEC will be handed out to
someone else.  The people in that organization will have _no clue_ how
to evaluate the goodness or badness of the DNSSEC procedures of said
contractors.  Or maybe one person in the company will, but he will be
doing the work of three people and won't have time to pay close
attention to any of this.  

The DNS is _not important_ to most of the people who have to rely on
it, any more than the details of my plumbing system are something I
think about every time I wash my hands (and yes, I have replaced my
own pipes).  Asking people to roll their keys all the time is like
telling them that they need to do annual maintenance checking the
washers in all their sinks, to make sure that they're not having
leaks.  Good, sane practice; but they're not going to do it.  They'll
notice when a drip starts, and that day they'll call a plumber.

> There is a reason people have "fire drills" on a periodic schedule.

When we have fire drills, in my experience, we don't actually set off
the alarms and run the sprinklers (or set the building on fire).  We
do it in a controlled, test way, with a mechanism to warn the fire
department and so on.  And actually, in many places, everyone knows
when a fire drill is happening.  We don't seem to have mechanisms for
all this stuff everywhere in the DNS.  Finally, there are places where
fire drills practically never happen -- I've never once been in a
movie theatre where a fire drill happened during a show, for
instance.  And for good reason: the risk of setting off a panic and
hurting people is much greater than the risk that people won't know
what to do in case of a real fire.

I'm not trying to say, "Never roll your keys under any circumstances."
I am arguing, however, that the advice in a document about how to
manage your systems has to contain second-order advice about
evaluating risk and reward, if we want that advice to be helpful.
Rolling keys entails some risk, and if that risk is greater than the
combination of the risk that the key is going to be compromised in the
key lifetime and the risk reduction from key rolling practice, then
the person deciding to do the key roll anyway is actually being
irresponsible: they're taking greater risk than need be.  Different
environments entail different results for that risk evaluation,
because the keys are not all of the same value.  The keys for
mytinycornerof.universe.example.com are just not as valuable as the
keys for the root, and that means I have to make trade-offs that might
be different than those for the root.  Isn't that obvious?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 21 Jan 2010 17:24:30 -0500 (EST)

> _______ signatures/days."

I did ask my local Waterloo based cryptographer (Ian Goldberg) this
question about a year ago for RSA-SHA1. And apart from his advise to use
RSASSA-PSS and not PKCS1-v1_5, he thought a year would be extremely safe.
I just asked another Toronto based cryptographer, Kelly Rose, the same
question, and he said he would not trust it for more then two years.

Also, consider this paper from July 2009:

https://documents.epfl.ch/users/l/le/lenstra/public/papers/ecdl.pdf

     Next considering special purpose hardware, the most optimistic
     approach suggests that sieving for a 1024-bit RSA modulus can be
     done in a year for about US $10,000,000, plus a one-time development
     cost of about US $20,000,000,

As for your specific birthday present, you will not get it. The same
paper says:

 	Estimates should thus not be read as threatening but as
 	confidence-inspiring.

> That's what I'd like for my birthday present this year.

How about a cookie instead?

Paul

---

From: Roy Arends <[email-masked]>
Date: Thu, 21 Jan 2010 17:36:10 -0500

> Fixing secretly compromised ZSKs is a side benefit.

Rolling to mitigate secretly compromised keys suggests that compromising a key is a one-off event. If its compromised once, you have to assume its compromised often. It will probably compromised after each roll. Compromising a key likely stems from bad operational hygiene, not from advances in cryptography. Rolling keys won't help here.

I agree with EKR. I don't appreciate the frequent rollover syndrome. 

Roy

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Jan 2010 14:36:57 -0800

>    cost of about US $20,000,000,

And if your attacker has a budget of $1,000,000? Or $100,000,000?

The point is that the numbers depend on your model of the attacker
more than on the cryptography.

-Ekr

---

From: Todd Glassey <[email-masked]>
Date: Thu, 21 Jan 2010 14:57:47 -0800

On 1/21/2010 12:12 PM, Eric Rescorla wrote:
> On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffman<[email-masked]>  wrote:
>    
Actually Eric if the credential is only valid for a period of time which 
is less than the amount of time needed with CPU Resource created by $D 
(i.e the money to pay for CPU $H) then the process is very relevant so 
the issue is how long is the credential negotiable for and is that 
number less than the perimeter of the 'can be hacked with these 
resources' ???

http://www.nvidia.com/object/cuda_home.html#

>> For most keys, no, at least for the next five years or so.
No its not.
>> That is, the *cost* of breaking a 1024-bit key, when that is feasible, is still much higher than the value of the broken key.
  The problem is that nVidia CUDA based brute force engines are 
available that produce 42TF of compute engine off the shelf and for 
under 10K... and gee whiz they rock for factoring. Especially when ten 
gamers get together and put 20 of the SLI enabled GX2 and other quad GPU 
cards which effectively sport 240 thread cores per card. Compare that to 
the wimpy Quad-Core P4's on the market today and you will start to see 
the future.

In this instance nVidia's TESLA systems rock 
http://www.nvidia.com/object/tesla_computing_solutions.html - Imaging 
what you can do to a PW with one of these running FreeBSD or Linux and 
John the Ripper. I think its less than 2 years before factoring engines 
based on nVidia Cores are common place outside the NSA.
>> Remember that a broken signing key is only valuable until the fact that it is broken is discovered and fixed. So, even if an attacker breaks your signing key, when he/she starts to use it for nefarious purposes and you discover that, you roll your key and the entire time of breaking the new key must be used again before they can mount another attack.
>>      
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.432 / Virus Database: 271.1.1/2636 - Release Date: 01/21/10 07:34:00
>
>

---

From: Todd Glassey <[email-masked]>
Date: Thu, 21 Jan 2010 15:03:22 -0800

> because what is right is surely related to other considerations.
Andrew you are right here - its not a matter of what is right - its a 
matter of "how to" and that's the key I think.
> the case under a lot of outsourcing contracts).
Hmmm - let me push back. Not necessarily - the real issue is the proper 
evidence of the functioning of the DNSOP is the key here. The problem is 
that DNS log data sucks now. It was designed by techies for debugging 
and not for evidence which is what it needs to be specifically. That 
said - the real issue is how chain of custody is maintained and proven 
after the fact since in the real time if the DNS doesnt work or works 
wrong theorhetically the user is bright enough to catch that, but  
longer term - how to you prove three years in the future that the 
resolutions done today actually happened and were done correctly.

 From my point of view this isnt about just working right in the present 
its about working right in creating enduring evidence of that operation.

Todd Glassey
> In that circumstance,

---

From: Jim Reid <[email-masked]>
Date: Thu, 21 Jan 2010 23:03:29 +0000

> I'd recommend that 'exercise the activity' is not done on critical  

I'd recommend the opposite. Sort of: carry out these drills in the  
production environment but clearly not on the systems that are  
actually handling the operational load.

If your processes and policies aren't up to the job of working in a  
critical production environment, they're fundamentally broken because  
they don't do what they're supposed to do. Think about it Roy. Key  
rollovers will *have* to be done in a production environment, and not  
always according to a previously planned schedule. So whatever  
processes and procedures someone devises for doing a key rollover  
should be robust enough to cope with emergencies such as a compromised  
key.

True mission critical environments know how to handle scheduled  
changes and unplanned interventions: -- applying patches, replacing  
hardware, OS upgrades, etc -- without compromising service. In such  
settings, a key rollover would just be another thing to add to the ops  
team's list and it shouldn't matter if that rollover was planned or not.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 21 Jan 2010 18:08:55 -0500 (EST)

> more than on the cryptography.

The full paper has a cost matrix. Though I just noticed they changed the
URL of the paper :(

Paul

---

From: Roy Arends <[email-masked]>
Date: Thu, 21 Jan 2010 18:55:11 -0500

On Jan 21, 2010, at 6:03 PM, Jim Reid wrote:

> I'd recommend the opposite. Sort of: carry out these drills in the production environment but clearly not on the systems that are actually handling the operational load.
> If your processes and policies aren't up to the job of working in a critical production environment, they're fundamentally broken because

Hold on a minute. I'm referring to 'exercise the activity' as in practicing the processes and policies. You are saying that processes and policies should be up to the job. Those are two different things.

> they don't do what they're supposed to do. Think about it Roy. Key rollovers will *have* to be done in a production environment, and not always according to a previously planned schedule.

Sure.

> So whatever processes and procedures someone devises for doing a key rollover should be robust enough to cope with emergencies such as a compromised key.

Absolutely. Until then, don't roll. 

> True mission critical environments know how to handle scheduled changes and unplanned interventions: -- applying patches, replacing hardware, OS upgrades, etc -- without compromising service. In such settings, a key rollover would just be another thing to add to the ops team's list and it shouldn't matter if that rollover was planned or not.

Absolutely. 

I'm all for proper policies, procedures, processes. You get there by (among other things) 'exercise the activity'. I'm also for that. I'm arguing that the exercising should not be done on critical production systems. Think about it Jim.

Roy

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Jan 2010 16:41:58 -0800

> The full paper has a cost matrix. Though I just noticed they changed the

Yes, but my point is that the safety period depends on your assumptions
about the attacker's resources, which is why this is not really a technical
issue.

-Ekr

---

From: Jim Reid <[email-masked]>
Date: Fri, 22 Jan 2010 00:57:13 +0000

On 21 Jan 2010, at 23:55, Roy Arends wrote:

> I'm arguing that the exercising should not be done on critical  
> production systems.

Argue all you like. :-) But if those procedures, policies and  
processes are not exercised on the critical production systems *for  
real* there is no way of knowing for sure if they'll work or not. It  
would be most unfortunate to discover that they don't work whenever  
there's a genuine reason for using them on the critical production  
environment. By all means test them and run exercises elsewhere, but  
they do need to be invoked from time to time in the live environment.  
And not just for drills.

---

From: Roy Arends <[email-masked]>
Date: Thu, 21 Jan 2010 20:42:21 -0500

On Jan 21, 2010, at 7:57 PM, Jim Reid wrote:

>> I'm arguing that the exercising should not be done on critical production systems.
> 
> Argue all you like. :-) But if those procedures, policies and processes are not exercised on the critical production systems *for real* there is no way of knowing for sure if they'll work or not.

You're contradicting yourself. Just minutes ago, you wrote:

"True mission critical environments know how to handle scheduled changes and unplanned interventions: -- applying patches, replacing hardware, OS upgrades, etc -- without compromising service. In such settings, a key rollover would just be another thing to add to the ops team's list and it shouldn't matter if that rollover was planned or not."

> It would be most unfortunate to discover that they don't work whenever there's a genuine reason for using them on the critical production environment.

Indeed it would. I'm not saying that procedures shouldn't be tested. I'm telling you that when you want to educate an SA, you do it elsewhere. If you want to test a procedure, you do that _within_ the company, on its own time schedule, without unnecessary announcements. I really hope you agree that its silly to roll a key frequently, say monthly and announce the exact time when you're going to roll it, giving miscreant another chance next month if they miss the opportunity to mess things up. That is what is currently happening. There is a danger in that. When I point that out, folks immediately grab RFC4641, telling me they _have_ to roll frequently.

> By all means test them and run exercises elsewhere,

Thank you!

> but they do need to be invoked from time to time in the live environment.

Sure. 

> And not just for drills.

Fine.

Roy

---

From: Paul Wouters <[email-masked]>
Date: Fri, 22 Jan 2010 00:09:11 -0500 (EST)

> about the attacker's resources, which is why this is not really a technical

It is also based on the presumed technological advances of attackers. If
you talk to a cryptographer about a 1024 bit RSA key, they will tell you
"don't use that anymore". When you tell them "well, it is very useful
to us to reduce packet size in DNS" they tell you "go use ECC".

We made a technological trade of. Though extremely conservative, all the
cryptographers (or really cryptanalysts) I talked to are more conservative
then we have been. Whether you call this technical or philosophical, does
not really change the issue. The model of the attacker is a fundamental
part of the cryptography.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Jan 2010 21:24:39 -0800

> part of the cryptography.

I really have no idea what you're talking about here. There is widespread
agreement about the technical difficulty of attacking RSA. The question
of how that impacts your behaviors has primarily an economic question,
not a cryptographic one.

With that said, cryptographers actually don't tend to think particularly deeply
about the attack model; rather they assume a certain fairly idealized model
of attacker capabilities and try to demonstrate that their systems have
certain properties under those models. This is fundamentally different
from the kind of thinking required here.

-Ekr

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 22 Jan 2010 07:45:45 -0500

On Fri, Jan 22, 2010 at 12:57:13AM +0000, Jim Reid wrote:
> invoked from time to time in the live environment. And not just for 
> drills.

That sounds rather like a claim that we need to go around and set
buildings on fire from time to time (or have levees break, or cause 7+
Richter-scale earthquakes, or pick your analogy) in order to make sure
that the procedures are in place.

It is simply not true that everything needs to be done "for real" in
order to be sure it can be done.  I don't think we should have live
nuclear-weapon ICBM tests just to see whether the reaction procedures
of the local elementary school are up to snuff.  As I've now said
several times, the risk of some activities is greater than the reward
from seeing how well your operation of that activity follows the
plans.

The question here is how great the risk of key rolling is: is it more
like live ICBM tests, or is it more like changing your underwear (the
procedures for which I'm sure we all hope everyone keeps in good
nick)?  I claim the answer to that question is, "It depends," and we
need to give people advice on how to decide where on the
nuclear-war/underpants scale they lie.  I think EKR and Paul have
suggested ways to say that.  I enclose below some additional
long-winded text in case any of it can be useful.

    Keys in use do not become weaker with continued use, and there are
    not strong arguments from a cryptographic point of view that keys
    need to be rolled frequently or even with any regularity.  

    Given the state of the cryptographic art as of this writing, the
    chances of a key (selected in accordance with the recommendations
    in this Section 3) being broken by cryptanalysis is exceeding low.
    It is important to evaluate continuously that risk.  When making
    an evaluation, it is important to remember that the main question
    is one of cost versus value: 

        1.  What will it cost an attacker to crack the key?

        2.  What will the benefit to the attacker be (i.e. what is the
    value of the key)?

        3.  How long can the attacker realistically expect to gain
    from the attack?

    To take a deliberately bad example, if it costs $1,000,000 to
    crack the key once a month, and the attacker can only actually use
    the compromised key one time before being detected, then the value
    of that single use needs to be at least $1,000,000 (however one
    calculates that value) to make the attack worth performing.

    Each key rollover comes with some risks and rewards.  Every key
    rollover runs a small risk that the new key will not be available
    somewhere in time for the old key to be removed, if only because
    of the possibility that a validator has misconfigured the old key
    as a preferred trust anchor.  Errors in the key rollover
    procedures or their execution can also lead to the new key not
    being available in time.  If some validating resolver attempts to
    use the old key, and cannot (or will not, by configuration) use
    the new key after the rollover has completed, then that validator
    will treat the zone as bogus.

    Sites that have well-automated and carefully-tested key rollover
    procedures, particularly if the site is well-monitored from
    diverse networks, are somewhat less likely to face long-term
    outages due to key rollover problems; at the same time, such
    high-value zones are more likely to suffer embarrassment from a
    botched key rollover.  By similar reasoning, a small site for
    which DNSSEC is at most a part-time occupation for one staff
    member might run great risk of outage during a key rollover, just
    because the testing and detection of DNS issues may not be as
    complete as at a larger site.  Most sites will fall in a continuum
    between these extremes.  Determining policy around key rollover --
    whether to do it, how frequently if so, and whether regularly if
    so -- is a matter of operational policy that needs to be
    established for each site, taking into account the considerations
    above.

Someone might be able to edit that into something less wordy and more useful.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Todd Glassey <[email-masked]>
Date: Fri, 22 Jan 2010 06:51:43 -0800

On 1/21/2010 9:24 PM, Eric Rescorla wrote:
> On Thu, Jan 21, 2010 at 9:09 PM, Paul Wouters<[email-masked]>  wrote:
>    
> about the attack model;
Understatement
>   rather they assume a certain fairly idealized model
Or how their crypto-algorithm works in production for that matter. The 
use model issue is why there is so much bad crytography out there IMHO

Todd Glassey
> Version: 8.5.432 / Virus Database: 271.1.1/2637 - Release Date: 01/21/10 19:34:00
>
>

---

From: Tony Finch <[email-masked]>
Date: Fri, 22 Jan 2010 16:56:56 +0000

> - Regular rolling can give you a false sense of security about your rolling process

How can you have any sense of security about your rolling process if you
don't exercise it?

Tony.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 22 Jan 2010 09:13:22 -0800

>How can you have any sense of security about your rolling process if you

Why do people think the opposite of "regular" is "never"?

--Paul Hoffman, Director
--VPN Consortium

---

From: Joe Abley <[email-masked]>
Date: Fri, 22 Jan 2010 12:52:05 -0500

On 2010-01-22, at 07:45, Andrew Sullivan wrote:

> order to be sure it can be done.

I think that's true. However, for procedures (manual or automated) that are required to function seamlessly and transparently in production, with no impact to service, I am generally in favour of exercising them regularly in production.

Additionally, with the case of key rolls, there are two sides to the exercise -- you need to be sure that you can do them seamlessly on the server side, and you also need to be sure that the client side can accommodate the change. The only way I can think of doing that in any real way is to roll your keys in production. You don't know your client base well enough on the Internet to be able to have them test against a lab (or test at all).

I don't think it matters whether the key roll schedule is perfectly periodic (e.g. every interval T) or event-driven (e.g. every time someone joins or leaves the operations team) but in general I am not comfortable relying on important machinery to work when you need it if it's not exercised.

If you need an analogy, I think generator testing is a better one than launching ICBMs at schools. You hope never to need your generator, but you test it regularly anyway just in case.

Joe

---

From: Edward Lewis <[email-masked]>
Date: Fri, 22 Jan 2010 12:50:36 -0500

>I'd recommend that 'exercise the activity' is not done on critical

There's a difference between "exercise" and test/training/etc.  You 
do want to "exercise" on the real systems.

>You have worked in more enlightened organizations than I, then.

Not trying to be funny, but there are a number of times in the thread 
that I thought to myself "geez, we all have 'different' operational 
situations."

Every organization is more enlightened than the others in some way 
and vice versa.

I am not saying this to stoke any commercial rivalries but as a 
comment that the draft document reflect that there are a wide array 
of operational practices and situations.  Not everyone out-sources, 
not everyone has high turnover.  And so on.

>Why do people think the opposite of "regular" is "never"?

Because that's the way it is. ;)

"cron does not play dice with the universe."

---

From: Alex Bligh <[email-masked]>
Date: Fri, 22 Jan 2010 18:05:46 +0000

> Why do people think the opposite of "regular" is "never"?

There seems to be some confusion of "regular" and "frequent" too.

-- 
Alex Bligh

---

From: Todd Glassey <[email-masked]>
Date: Fri, 22 Jan 2010 11:43:23 -0800

On 1/22/2010 10:05 AM, Alex Bligh wrote:
>
>
> --On 22 January 2010 09:13:22 -0800 Paul Hoffman 
> <[email-masked]> wrote:
>

You mean a periodic process to rotate the keys... OK what is the 
periodicity of this?
>> Why do people think the opposite of "regular" is "never"?
You mean why to techies think the opposite of regular is never...
> There seems to be some confusion of "regular" and "frequent" too.
Agreed - so again what is the periodicity of the key rolls.

Todd
> Version: 8.5.432 / Virus Database: 271.1.1/2638 - Release Date: 01/22/10 07:34:00
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 22 Jan 2010 12:35:17 -0800

At 8:18 PM +0000 1/22/10, [email-masked] wrote:
>On Fri, Jan 22, 2010 at 09:13:22AM -0800, Paul Hoffman wrote:
>	to borrow from Andrew - let me posit an analogy...
>
>	would you rather have your LASIX or LIOP  surgery done
>	by someone who has done 12,000 such procedures and
>	does a couple a week or someone who has done a dozen
>	and does them about every couple years or so?
>
>	sure, the doctor who does them all the time -might- get
>	sloppy and cut corners  --  but is that worse than someone
>	who has only passing understanding of what they are actually
>	doing?
>
>	the risk isn't -never-, the risk is lack of experience.

Why do people think this is about "the risk" instead of "the risks"?

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 22 Jan 2010 19:17:09 -0500

On Fri, Jan 22, 2010 at 03:23:02PM +0000, [email-masked] wrote:

> 	the apparent nub of the argument is... we need to be
> 	able to do this rollover thing, but if we screw up
> 	it will be hard to put back together... so we won't
> 	actually do the task - and hope that we'll never	
> 	pull the trigger.

That's question-begging.  The exact question under dispute is whether
"we need to be able to do this rollover thing".  Maybe one needs to be
able to do it, and maybe not, and maybe the event itself is so rare in
some zones that treating every occasion as the 1st time is the right
approach.  That's exactly what's up for debate.  Some (I am among
them) claim that there's a risk/reward trade-off, and others seem to
start with the premise that it is a necessary event.  Only if you
accept the latter can you argue that it's the sort of operational
event that must be undertaken with any regularity, and even then I
think the argument is weak.

> 	DNS operators -have- to pay attention these days or 
> 	the system will stop working.  

This is true, but it's unrelated to key rolls.  It has to do with the
resigning period, which is a completely different issue.

On Fri, Jan 22, 2010 at 12:52:05PM -0500, Joe Abley wrote:

> I don't think it matters whether the key roll schedule is perfectly
> periodic (e.g. every interval T) or event-driven (e.g. every time
> someone joins or leaves the operations team) but in general I am not
> comfortable relying on important machinery to work when you need it
> if it's not exercised.

Ok, except that each exercise of this machinery is in fact a case of
"needing it", since you're going to do exactly the things you'd need
to do when you need it.  The problem with the key roll as "exercising
the machinery" is that it's a destructive test.  

> If you need an analogy, I think generator testing is a better one
> than launching ICBMs at schools. You hope never to need your
> generator, but you test it regularly anyway just in case.

Good analogy.  What you do here depends on your operation.  If you are
the sort of hugely-automated total 24x7 shop that needs to be able to
prove in a controlled fashion that your generators all work, come on
line, and take the load, then maybe (and only maybe) you turn the
whole thing on, flip everything over to generators, and so on from
time to time (in a controlled way) to prove that it all works.  But if
you have a tiny generator that is supposed to allow you to operate a
couple things in your house in case of a snowstorm, all you do is fire
it up and make sure it produces power.  Which sort of test you ought
to do is governed by what kind of needs you have.

Since I think I've sung that refrain to everyone's boredom, however,
I'll shut up about it now.  

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: David Conrad <[email-masked]>
Date: Fri, 22 Jan 2010 18:07:12 -0800

Andrew,

> Which sort of test you ought to do is governed by what kind of needs you have.

I've been in places where folks really needed to rely on generators kicking in during a power outage.  When the generators turned out to be reasonably good at being pieces of industrial art because folks forgot to fill the diesel tank, there were many unhappy customers.  Oddly, a periodic test of the backup generators was soon instituted.

Pragmatically speaking, which sort of tests you do depend on how much you care.  If you're going to go to the trouble of signing your zone, it would seem to me it implies your level of care is high enough that you'd actually try to do things so they don't break when you need them.  If not, why bother signing?

> Since I think I've sung that refrain to everyone's boredom, however, I'll shut up about it now.  

Yep, I've given up too.  Operationally, people will do what they think is appropriate regardless of what is written in an RFC.  In some version of an ideal world, folks who care about "doing the right thing" could point to an RFC and ask vendors if they implement that RFC (presuming the RFC describes doing the right thing).  I don't fully get why it makes sense to dumb down RFCs in this context, but I'm sure it's because I'm missing something.

Regards,
-drc

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Jan 2010 21:14:26 -0800

> Why do people think this is about "the risk" instead of "the risks"?

I haven't formed a useful opinion one way or the other about the operational
value of frequent key rollovers. However, it seems to me that the value
of those practices is more or less independent of key size, so we've
travelled fairly far afield from the original claim that we need rollovers
to compensate for being forced to use overly-short RSA keys.

-Ekr

---

From: Niall O'Reilly <[email-masked]>
Date: Sat, 23 Jan 2010 15:46:00 +0000

> There seems to be some confusion of "regular" and "frequent" too.

	Not to mention conflation of "regular" and "periodic".

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 23 Jan 2010 09:36:03 -0800

At 6:07 PM -0800 1/22/10, David Conrad wrote:
>Operationally, people will do what they think is appropriate regardless of what is written in an RFC.  In some version of an ideal world, folks who care about "doing the right thing" could point to an RFC and ask vendors if they implement that RFC (presuming the RFC describes doing the right thing).  I don't fully get why it makes sense to dumb down RFCs in this context, but I'm sure it's because I'm missing something.

You are. People will tell operators "an RFC exists that covers your operation, so you must follow it". We see that all the time in the IETF in general, and I believe at least one person said it at the mic at the DNSOP WG in Dublin.

Thus, we really want our operational RFCs to reflect the widest range of best practices that are actually considered "best". If we get lazy and just list one scenario, we will be hurting the Internet by restricting some organizations to following one model when another might have made more sense for them.

--Paul Hoffman, Director
--VPN Consortium

---

From: Thierry Moreau <[email-masked]>
Date: Sun, 24 Jan 2010 12:26:58 -0500

Paul Hoffman wrote:
>> Operationally, people will do what they think is appropriate regardless of what is written in an RFC.  In some version of an ideal world, folks who care about "doing the right thing" could point to an RFC and ask vendors if they implement that RFC (pre
>>     
> suming the RFC describes doing the right thing).  I don't fully get why it makes sense to dumb down RFCs in this context, but I'm sure it's because I'm missing something.
>
> Thus, we really want our operational RFCs to reflect the widest range of best practices that are actually considered "best". If we get lazy and just list one scenario, we will be hurting the Internet by restricting some organizations to following one mo
> del when another might have made more sense for them.
>   
Then, you perpetuate the IT security paradigm where the operator 
complies to an auditable specifications-based operations guide, but the 
attackers are given opportunities to pass through the cracks.

That's because a given (operational) instance applies a single scenario 
that is unique and never fully examined: the RFC approach with multiple 
scenarios fails to provide a full analysis opportunity for any single 
one (that would be obviously out of scope in some aspects).

For instance, full review of an operational plan requires disclosure of 
internal security measures (around personnel turnover) that are not 
typically subject to formalization in a form suitable for IT security 
analysis.

I don't have an answer for this paradox.

Regards,

- Thierry Moreau

---

From: Edward Lewis <[email-masked]>
Date: Mon, 25 Jan 2010 12:56:09 -0500

>to compensate for being forced to use overly-short RSA keys.

What I've taken from this thread is that choices made for key 
management are not driven by cryptographic considerations.  What I 
wonder now is whether my choice for key size is too big - the cost of 
that is the DNS response datagram size.

I envision monthly changes of the ZSK and annual changes of the KSK. 
I can't see any savings in extending the periodicity of this, but I 
can see savings in lowering the number of bits needed to send the 
public key and signature along.

Last time I looked (a few months ago) most signed TLDs to use 2048 
bit KSKs and 1024 bit ZSKs.   Perhaps there is no reason to have two 
different sized keys, I would guess that since "a chain is only as 
strong as its weakest link" all keys could be dropped to 1024, or 
even less.

But what nags at me are the NIST recommendations that talk of a keys 
having so many bits of randomness - like a 1K or 2K key having 112 
bits.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 25 Jan 2010 13:05:35 -0500 (EST)

On Mon, 25 Jan 2010, Edward Lewis wrote:

> Last time I looked (a few months ago) most signed TLDs to use 2048 bit KSKs 
> and 1024 bit ZSKs.   Perhaps there is no reason to have two different sized 
> keys, I would guess that since "a chain is only as strong as its weakest 
> link" all keys could be dropped to 1024, or even less.

The weakness of a key is partially determined by the length of its usage
period. If you plan to use the KSK for a period 12 times longer, making it
1024 is not making it equal to the ZSK strength of "1024 for 30 days"

I don't think people have experienced serious troubles with 2048 bit keys,
though if you want to go higher, you're probably better of waiting for ECC,
as that will give you smaller signatures compared to RSA with the same key
size. But AFAIK, no dns implementation supports ECC yet.

Paul

---

From: Francis Dupont <[email-masked]>
Date: Mon, 25 Jan 2010 18:32:04 +0000

In your previous mail you wrote:

   But AFAIK, no dns implementation supports ECC yet.
   
=> *** flame war ON ***

In fact it is no true: GOST (in its second version which will be used
for DNSSEC) is based on ECC.

*** flame war OFF ***

[email-masked]

PS: there is no real technical issue for ECC based DNSSEC: all it is
needed is reasonable support in not very last OpenSSLs.
So the real problems are:
 - a good draft
 - some consensus
 - IETF publication delays
IMHO we should ask Russ to nominate a cryptographer (or himself)
to re-initiate the process from the first step: a good draft
(here good is sound from a crypto point of view, easy to implement
(I already explained what I meant by this) and without a zillion
different options (what I believe was the problem of previous attempts)).

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Jan 2010 10:44:12 -0800

At 1:05 PM -0500 1/25/10, Paul Wouters wrote:
>>Last time I looked (a few months ago) most signed TLDs to use 2048 bit KSKs and 1024 bit ZSKs.   Perhaps there is no reason to have two different sized keys, I would guess that since "a chain is only as strong as its weakest link" all keys could be dropped to 1024, or even less.
>

Exactly right, but still mostly irrelevant. What is the value of the keys you are talking about? Is one so valuable that an attacker would spend the amount of money and time needed to break it? What value would they get from that attack?

More importantly: could the attacker get move value from spending the money and time breaking a different key of the same size? Look at the myriad of 1024-bit keys in the world whose lifetimes are much longer than a year. If any of them would yield a better result for the attacker, he won't bother with yours; if yours is the highest value, he won't bother with the others.

If you really believe that a 1024-bit ZSK key is the appropriate size for a month, then you only need something about 12 times as strong for the KSK under the same threat model. 1536 bits would be much more than you needed; a rough estimate would be 1200 bits. The reason these numbers are never discussed in DNSOP is because no one is discussing their actual threat model and the estimated value of the attacks.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Rose, Scott W." <[email-masked]>
Date: Mon, 25 Jan 2010 14:18:37 -0500

> strong as its weakest link" all keys could be dropped to 1024, or
You can - sure.  Why not?  For a while the NIST recommendation was to have
2048 bit ZSK and KSK's.  Now that better tools are out there, no need to go
by file sizes anymore :)

> having so many bits of randomness - like a 1K or 2K key having 112

I've been assured there is some sort of calculation involved, but I can't do
it.  

All of the NIST recommendations are really grounded in the (Fed) PKI world.
DNSSEC isn't big enough (or well known) to justify a separate set of policy
recommendations.  NIST(via the NSA) has decided that 1024 bit RSA could be
vulnerable soon, so a stake in the ground is planted to move PKI certs (and
everything else) to 2048 bit RSA.  After much debate, we (networking) got
them (Comp Security) to back down and agree that 1024 bit was still ok, as
long as the key is changed ~3 months (at max).  Otherwise it would policy to
have both keys be 2048 bits.

Scott

http://www.dnsops.gov/

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Jan 2010 11:24:58 -0800

>different options (what I believe was the problem of previous attempts)).

That might be draft-hoffman-dnssec-ecdsa. I let it expire earlier this month because the DNSEXT WG is still not clear on the allowable statuses for crypto documents, but have today revived it based on your comment.

If you don't consider this to be "a good draft", I am quite open to suggestions for improvement!

--Paul Hoffman, Director
--VPN Consortium

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 26 Jan 2010 11:44:33 +0900

Paul Hoffman wrote:

> The reason these numbers are never discussed in DNSOP is because
> no one is discussing their actual threat model and the estimated
> value of the attacks.

The practical threat model is frequent social attacks on a trusted
third party or two, which means there is no such thing as a trusted
third party.

That is, PKI, including DNSSEC, merely gives false sense of security.

						Masataka Ohta

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Jan 2010 21:59:12 +0000

That might be draft-hoffman-dnssec-ecdsa.

=> IMHO we have a problem with ECDSA (and DSA too): verify is too slow,
in particular it is slower than signature. You can expect a crypto
accelerator for a master authoritative server, but not (yet?) for
a caching server... I think this killed DSA in the real world
(no DNSSEC deployment uses it).

Thanks

PS: I have another (very technical) concern: I deeply dislike crypto
algorithms which require a random value for signing. DSA has this
IMHO bad property and ECDSA shares it.

---

From: [email-masked]
Date: Mon, 25 Jan 2010 19:58:24 +0000

thanks paul.