Subject: Re: [DNSOP] [dnsext] Why ZSK rollover is a Bad Idea (tm)

From: Olaf Kolkman <[email-masked]>
Date: Wed, 7 Oct 2009 09:23:18 +0100

On Oct 6, 2009, at 10:08 PM, Eric Rescorla wrote:

> [ Moderators note: Post was moderated, either because it was posted by
>   a non-subscriber, or because it was over 20K.
>   With the massive amount of spam, it is easy to miss and therefore
>   delete relevant posts by non-subscribers.
>   Please fix your subscription addresses. ]
>
> On Tue, Oct 6, 2009 at 2:02 PM, Paul Hoffman <[email-masked]>  
> wrote:
>> At 4:09 PM -0400 10/6/09, Nicholas Weaver wrote:
>>> Eric Rescorla has an explanation why the zone signing key rollover  
>>> mechanism in DNSSEC for the root is a bad idea:  It doesn't  
>>> improve security and only makes things more complicated:
>>>
>>> http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html
>>>
>>>> The more general lesson here is that changing keys rapidly is  
>>>> nearly useless as a method of preventing analytic attacks. It's  
>>>> almost never practical to change keys frequently enough to have a  
>>>> significant impact on the attacker's required level of effort. If  
>>>> you're that close to the edge of a successful attack, what you  
>>>> need is a stronger key, not to change your weak keys more  
>>>> frequently. In the specific case of DNSSEC, just expanding the  
>>>> size of the packet by 10 bytes or so would have as much if not  
>>>> more security impact at a far lower system complexity cost.
>>
>> I won't speak for Ekr, but I see his argument being against ZSKs in  
>> general, not just at the root. It's the same
>> argument I have tried to make in DNSOP.
>
>
> I don't have a general position on ZSKs--perhaps it's a good idea for
> some other reason--but I don't
> think that rolling the keys over at high rates provides any
> significant security benefit, no matter
> where in the hierarchy you're doing it.

Really this is an DNSOP issues, more specifically an issue for  
RFC4641bis.

[I've added dnsop, please remove namedroppers when replying to this  
note]

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.

I've added this as an issue to the issue tracker.

See (http://www.nlnetlabs.nl//svn/I-D-dnsop-rfc4641bis/trunk/open-issues/ 
)

I hope I can address a few of the issues before Yokohama.

--Olaf

________________________________________________________

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

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 7 Oct 2009 10:33:15 +0100

On Oct 7, 2009, at 9:23 AM, Olaf Kolkman wrote:

>  hope I can address a few of the issues before Yokohama.

s/Yokohama/Hiroshima/

Should I call my travel office? ;-)

--Olaf

---

From: Chris Thompson <[email-masked]>
Date: 07 Oct 2009 11:15:39 +0100

On Oct 7 2009, Olaf Kolkman wrote:

[...]
>> http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html
[...]
>[I've added dnsop, please remove namedroppers when replying to this  

Well, OK. This is arguably off-topic for both lists, but I was struck
by Eric quoting from

 http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

| First, there are Key Signing Keys (KSK) which are used to sign
| other DNSKEY records and the DS records.
                       ^^^^^^^^^^^^^^^^^^

I wonder what gave them the idea that DS records were signed with
KSKs rather than (the parent's) ZSKs?

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Joe Abley <[email-masked]>
Date: Wed, 7 Oct 2009 14:22:52 +0100

[from a namedroppers thread, re-pointed as per Olaf's suggestion below]

> the (zone) operator may need to be replaced.

I skimmed through 4641 to try and refresh my memory, but couldn't find  
the discussion on ZSK rollover frequency. No doubt this is my  
deficiency.

 From my perspective the operational argument is that procedures which  
are rarely exercised may not be exercised well when they are needed (a  
backup that is not regularly tested cannot really be relied upon; a  
protect path that is never used might not work when it is needed, etc).

Frequent key rollover has the operational benefit of when you need to  
do an emergency roll you know the procedures work.

 From this perspective we might roll a ZSK more frequently than a KSK  
because the ZSK needs to be stored on-line to facilitate re-signing  
when the zone changes. With the KSK we have the option of keeping it  
off-line, and arguably the risk of compromise is consequently lower.  
Regular testing of the machinery is still important, however.

I am no crypto expert, but ekr's concern over the cryptographic  
benefits of frequent key roll seemed entirely reasonable.

I think the operational benefit is real, however.

Joe

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 07 Oct 2009 10:14:58 -0400

Joe Abley wrote:
> the discussion on ZSK rollover frequency. No doubt this is my deficiency.
>
The EKR's concern and the operational benefits are compatible. I.e. roll 
the ZSK per operational requirements, and use a ZSK key size adequate 
for longer-term resistance to brute force cryptanalysis.

Regards,

- Thierry Moreau
>
> Joe
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Roy Arends <[email-masked]>
Date: Wed, 7 Oct 2009 16:21:58 +0200

On Oct 7, 2009, at 3:22 PM, Joe Abley wrote:
> I skimmed through 4641 to try and refresh my memory, but couldn't  
> find the discussion on ZSK rollover frequency. No doubt this is my  
> deficiency.
>
> From my perspective the operational argument is that procedures  
> which are rarely exercised may not be exercised well when they are  
> needed (a backup that is not regularly tested cannot really be  
> relied upon; a protect path that is never used might not work when  
> it is needed, etc).
>
> Frequent key rollover has the operational benefit of when you need  
> to do an emergency roll you know the procedures work.
>

I find it worrying that folks intend to test or practice operational  
procedures by doing it often on a live production system. What if that  
test or practice fails? "Whoops, we were testing it on the live  
system, we failed, good thing we called it a test"

There is also a risk involved by rolling keys over regularly.  
Especially when the schedule is publicly announced. "If your attack  
fails, we will have write access to the keystore _every month_, on the  
1st, at exactly 3 am cest".

I fail to see the operational benefit of "Frequent Rollover Syndrome".

Roy

---

From: Joe Abley <[email-masked]>
Date: Wed, 7 Oct 2009 15:35:34 +0100

On 2009-10-07, at 15:21, Roy Arends wrote:

> procedures by doing it often on a live production system. What if  
> that test or practice fails? "Whoops, we were testing it on the live  

I would find that worrying too. I was talking about exercising  
production machinery, not testing it. There's a difference.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Oct 2009 08:25:21 -0700

At 2:22 PM +0100 10/7/09, Joe Abley wrote:
>From this perspective we might roll a ZSK more frequently than a KSK because the ZSK needs to be stored on-line to facilitate re-signing when the zone changes. With the KSK we have the option of keeping it off-line, and arguably the risk of compromise is consequently lower. Regular testing of the machinery is still important, however.

Please define "on-line" and "off-line". In the deployments I have heard of, both types of keys are stored with the same security procedures, but the ZSK might be stored in a physically different location (or not). The operational aspects of using the two keys are nearly identical.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Oct 2009 06:44:09 -0700

On Wed, Oct 7, 2009 at 6:22 AM, Joe Abley <[email-masked]> wrote:
>> Really this is an DNSOP issues, more specifically an issue for RFC4641bis.
>>
>> [I've added dnsop, please remove namedroppers when replying to this note]
>>
> I skimmed through 4641 to try and refresh my memory, but couldn't find the
> discussion on ZSK rollover frequency. No doubt this is my deficiency.
>
> From my perspective the operational argument is that procedures which are
> rarely exercised may not be exercised well when they are needed (a backup
> that is not regularly tested cannot really be relied upon; a protect path
> that is never used might not work when it is needed, etc).
>
> Frequent key rollover has the operational benefit of when you need to do an
> emergency roll you know the procedures work.

I see this argument, but I'm not sure I buy it.

Because DNSSEC has no concept of revocation list or online revocation,
keys remain valid until they expire, so lifetimes must be short (I don't
think 3 months is crazy here, though I would have been tempted to go
even shorter). This means you will be regularly signing new ZSKs, even
if the new ZSKs are the same as the old ZSKs. This will exercise most
of the relevant code and some of the procedures.

Similarly, because there is no way to do immediate key revocation,
you're stuck with having the compromised key valid for weeks or months,
so it's not like you don't have time to figure out the rest of the procedures
if you don't have them exactly right.

> From this perspective we might roll a ZSK more frequently than a KSK because
> the ZSK needs to be stored on-line to facilitate re-signing when the zone
> changes. With the KSK we have the option of keeping it off-line, and
> arguably the risk of compromise is consequently lower. Regular testing of
> the machinery is still important, however.

Again, this seems like an argument for the ZSK/KSK split, which I'm not really
arguing against (I haven't developed an opinion). My argument is purely
against generating a new ZSK every time you sign it with the KSK. I don't
think that provides much security benefit and certainly does have plenty of
room for error.

-Ekr

---

From: Joe Abley <[email-masked]>
Date: Wed, 7 Oct 2009 16:47:39 +0100

On 2009-10-07, at 16:25, Paul Hoffman wrote:

>> From this perspective we might roll a ZSK more frequently than a  
>> KSK because the ZSK needs to be stored on-line to facilitate re- 
>> signing when the zone changes. With the KSK we have the option of  
>> keeping it off-line, and arguably the risk of compromise is  
>> consequently lower. Regular testing of the machinery is still  
>> important, however.
>
> Please define "on-line" and "off-line".

The ZSK is exercised every time the zone changes. For some zones this  
is every few seconds. For the root zone it's twice per day. The  
equipment that performs the signing operation might well need to make  
use of the ZSK in an automated fashion, without human operators being  
present. This scenario is what I meant by "on-line".

The KSK is exercised every time a signature over the apex DNSKEY RRSet  
is required. This might be far more infrequent than the ZSK use  
described above. If so, it might be plausible to store the KSK on a  
device which has no network access and no power, in a secure facility,  
and to make the use of it a manual operation involving procedures,  
auditors, witnesses, etc. This is what I meant by "off-line".

I appreciate that there are other perfectly valid operational  
approaches in which the KSK is also kept on-line.

> In the deployments I have heard of, both types of keys are stored  
> with the same security procedures, but the ZSK might be stored in a  
> physically different location (or not). The operational aspects of  
> using the two keys are nearly identical.

Joe

---

From: Doug Barton <[email-masked]>
Date: Wed, 07 Oct 2009 23:14:11 -0700

Roy Arends wrote:
> test or practice fails? "Whoops, we were testing it on the live system,
> we failed, good thing we called it a test"
> 
> There is also a risk involved by rolling keys over regularly. Especially
> when the schedule is publicly announced. "If your attack fails, we will
> have write access to the keystore _every month_, on the 1st, at exactly
> 3 am cest".
> 

Roy,

I know you understand the concept that no matter how well you practice
something in the QA lab you're never really _sure_ it works till you
do it "in the wild." I think that at least in the early days of actual
DNSSEC deployment (which we have barely stepped into atm) it's very
reasonable to exercise all parts of the system now, under (relatively)
controlled conditions so that down the road if we reach a point where
we are forced to do an emergency key rollover on an "important" zone
we'll have some level of comfort (or at least know where to look for
things to break).

Down the road I tend to agree with you that "frequent" KSK rollover
will probably not have much benefit, but if I were administering a
zone for which DNSSEC was critical I'd probably do it once a year just
to keep all parts of the machine lubricated.

Doug

-- 

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 8 Oct 2009 12:06:54 +0100

On Oct 7, 2009, at 2:44 PM, Eric Rescorla wrote:

>> KSK because

Aha, I agree, FWIW there is no such requirement/suggestion in 4641 or  
4641 bis.

--Olaf

---

From: Todd Glassey <[email-masked]>
Date: Thu, 08 Oct 2009 10:39:24 -0700

> to keep all parts of the machine lubricated.
Doug - the key changes will want to be in accordance with corporate 
policy for all identity token management and should be administered as 
such. That generally means in audited company's a formal review once a 
year or more often. Because of this and since the DNSSEC services will 
become a key part of Internet presence management, these will also need 
to be reviewed as part of any formal IT audit practice as well.

Todd Glassey (as an Auditor).
>
> Doug
>
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.421 / Virus Database: 270.14.7/2421 - Release Date: 10/07/09 20:49:00
>
>