Subject: [dnsext] historal root keys for upgrade path?

From: Paul Wouters <[email-masked]>
Date: Tue, 25 Jan 2011 12:53:11 -0500 (EST)

A very large router vendor is about to make it mandatory that new devices
they produce use dnssec by default. One issue that comes up with that
is what happens if these devices were off long enough for a rollover to
have happened and the RFC5011 bit/key has been retired.

Are there plans to create a zone with all old root keys, that all sign the
DNSKEY RRset (eg rootkeys.root-servers.net) so that having ANY one old root
key could lead you to get a signed version of the latest root key? This way
you could disable DNSSEC to resolve rootkeys.root-servers.net, use your
current key to confirm the latest key, configure it, and drop the cache,
and you're golden.

Is something like this even possible? I'm not sure what happens to the
root private keys once they are retired...

Paul

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Tue, 25 Jan 2011 11:01:58 -0700

Paul,

See: draft-wijngaards-dnsop-trust-history-02

Abstract:
When DNS validators have trusted keys, but have been offline for a
longer period, key rollover will fail and they are stuck with stale
trust anchors.  History service allows validators to query for older
DNSKEY RRsets and pick up the rollover trail where they left off.

/S
----------------------------------------------------------------------
Stephan Lagerholm
Senior DNS Architect, M.Sc. ,CISSP
Secure64 Software Corporation, www.secure64.com
Cell: 469-834-3940

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Wouters
Sent: Tuesday, January 25, 2011 11:53 AM
To: dnsext List
Subject: [dnsext] historal root keys for upgrade path?

A very large router vendor is about to make it mandatory that new
devices
they produce use dnssec by default. One issue that comes up with that
is what happens if these devices were off long enough for a rollover to
have happened and the RFC5011 bit/key has been retired.

Are there plans to create a zone with all old root keys, that all sign
the
DNSKEY RRset (eg rootkeys.root-servers.net) so that having ANY one old
root
key could lead you to get a signed version of the latest root key? This
way
you could disable DNSSEC to resolve rootkeys.root-servers.net, use your
current key to confirm the latest key, configure it, and drop the cache,
and you're golden.

Paul
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 25 Jan 2011 13:29:24 -0500

> current key to confirm the latest key, configure it, and drop the cache,

I think the answer is
http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02
(and the opposition it has faced).

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 25 Jan 2011 13:31:11 -0500 (EST)

> DNSKEY RRsets and pick up the rollover trail where they left off.

Ok, so the next question is, can and will the root implement this? Because
that's really the main key that needs this.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Jan 2011 11:23:40 -0800

> root private keys once they are retired...

It is possible, but not in the way you seem to be thinking. If you 
trusted that hardware/software vendor to securely populate your trust 
anchor store originally, you can trust them to do so in the future as well.

One simple method would be, when you see you have a stale trust anchor 
and no way to use 5011 to get a fresher one, to securely ask the vendor 
for the new trust anchor out of band (that is, not using the DNS). There 
are lots of ways to do this, and none need to be standardized. One 
simple method is to do a HTTP-over-TLS query to a pre-loaded IP address 
that is controlled by the vendor, and validate the session with a 
certificate that is not tied to the DNS. Another simple(r?) method is 
SSH to an IP address controlled by the vendor (and so on).

Bootstrapping is hard, but once you have done it, you can reuse the 
trust logic you used to do it again.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 25 Jan 2011 15:12:04 -0500 (EST)

On Tue, 25 Jan 2011, Paul Hoffman wrote:

> It is possible, but not in the way you seem to be thinking. If you trusted 
> that hardware/software vendor to securely populate your trust anchor store 
> originally, you can trust them to do so in the future as well.

Well, this is the vendor asking "do we really need to build something ourselves"

The anser seems to be "yes". It also means that some devices will fail due to
firewall rules if this updating happens outside of the DNS scope.

> Bootstrapping is hard, but once you have done it, you can reuse the trust 
> logic you used to do it again.

Not neccessarilly. Bootstreap happens on a desk at the sysadmin office, not
neccessarilly on the switch in the production environment....

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Jan 2011 12:28:54 -0800

> firewall rules if this updating happens outside of the DNS scope.

I don't understand this. I proposed that the updating procedure use 
fixed IP addresses; are you saying that there are firewalls that prevent 
such communication unless there was a DNS lookup first?

> neccessarilly on the switch in the production environment....

There is no reason why it can't happen at the switch itself, assuming 
that you have not turned off the "trust the vendor to bootstrap DNSSEC" 
option in the switch's config.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 25 Jan 2011 15:47:10 -0500 (EST)

On Tue, 25 Jan 2011, Paul Hoffman wrote:

> I don't understand this. I proposed that the updating procedure use fixed IP 
> addresses; are you saying that there are firewalls that prevent such 
> communication unless there was a DNS lookup first?

I dount many switches/routers deployed at $customer can just access a random
$vendor IP, yes.

> There is no reason why it can't happen at the switch itself, assuming that 
> you have not turned off the "trust the vendor to bootstrap DNSSEC" option in 
> the switch's config.

But dong tftp,http or even ssh is a much different ACL then "doing more DNS
through the $company assigned forwarder".

Paul

---

From: Brian Dickson <[email-masked]>
Date: Tue, 25 Jan 2011 17:48:53 -0400

Here's an idea, which relies on "conventions" rather than "standards".
I.e. can be implemented unilaterally by $vendor, independent of anything else.

The basic idea is that DNSSEC relies on verification, and doesn't
*really* care where
the answer itself comes from.

And thus, anyone can run their own "copy" of any zone, even the root
zone, just by mirroring/copying/caching.

The scheme is, have copies of the root zone at $IPn inside $vendor's IP space.
Whenever the root zone key rolls, increment the last octet of $IPn
(thus $IP(n+1) = $IPn + 1).

The old root zone copy authenticates okay, and this creates a suitable
trust anchor for rootzone.$vendor.$tld.

The content of rootzone.$vendor.$tld is a set of new hints and copy of
the root zone trust anchor.

Following the new hints to $IPn+1 permits the new trust anchor to be verified.

I'm not sure, but I *think* this works (modulo errors or omissions).

It might be necessary to have the bootstrap start with a static trust
anchor and set of root hints inside rootzone.$vendor.$tld...

Brian

On Tue, Jan 25, 2011 at 4:47 PM, Paul Wouters <[email-masked]> wrote:
>> I don't understand this. I proposed that the updating procedure use fixed
>> IP addresses; are you saying that there are firewalls that prevent such

---

From: Tony Finch <[email-masked]>
Date: Wed, 26 Jan 2011 14:44:48 +0000

> firewall rules if this updating happens outside of the DNS scope.

You probably want to implement the bootstrap using a very long-lived trust
anchor for a fixed vendor zone on a fixed IP address. Many vendors will
have to support their bootstrap anchors for about ten years!

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 26 Jan 2011 09:57:26 -0500

If you want to distribute keys for immediate use in the DNS, use the
infrastructure designed for that purpose.

If you want to perform long term trust root management, use an architecture
that is designed for that purpose.

X.509v3 is designed to deal with TA keys that are valid for decades. There
is experience doing that. There is infrastructure that exists to perform
management of such keys in a high security environment. And it is possible
to outsource management of such to several providers and is is possible to
buy the equipment to do so in-house.

As a general rule, if I install hardware in my enterprise, it is going to
have to chain to my root or one that I select.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Jan 2011 09:58:21 -0500 (EST)

> have to support their bootstrap anchors for about ten years!

Ideally, this would be vendor neutral, and survive company merges, or vendors going
belly up, or vendor pool IP address changes, etc.

If vendors do this then all vendors have to do it themselves. Also, they have to use
a different bootstrap because only IANA has the private keys for the root zone to
do this in a way that we can use DNSKEY signatures from old to newer keys.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Jan 2011 10:06:41 -0500 (EST)

On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote:

> If you want to distribute keys for immediate use in the DNS, use the infrastructure designed for that purpose.
> If you want to perform long term trust root management, use an architecture that is designed for that purpose.
> 
> X.509v3 is designed to deal with TA keys that are valid for decades. There is experience doing that. There is infrastructure that exists to perform
> management of such keys in a high security environment. And it is possible to outsource management of such to several providers and is is possible to buy
> the equipment to do so in-house.

Which CA(s)s would we have to make the products trust? IANA seems to
be using Godaddy today. Is that guaranteed to last forever? If not,
then how is a device supposed to know which CA IANA has chosen at some
time in the future? Do we just have to trust all 1500+ commercial CA? 
And deal with all the revocations? And how to install new ones, using
what trust? And remember, this is a switch or router, not a browser or
an OS with the "update now" button.

Remember this has to work on a product that has just been factory defaulted
to a config from 10 years ago, and the device is EOL with no firmware upgrades.

> As a general rule, if I install hardware in my enterprise, it is going to have to chain to my root or one that I select.

That's awesome for your enterprise, but the question here transcends
the single enterprise or the single vendor area.

What we are looking at is some guaranteed (preferably DNS but could be http)
based linked list of DNSKEY's that sign each other to show transfer of trust.

This means with ONE original trusted key, the device can climb up to the current
root key in a trusted way. Adding X.509/CA chains solves nothing and adds more
complications.

Paul

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 Jan 2011 11:07:05 -0500

At 10:06 -0500 1/26/11, Paul Wouters wrote:

>This means with ONE original trusted key, the device can climb up to the
>current root key in a trusted way. Adding X.509/CA chains solves nothing
>and adds more complications.

I've been opposed to DNSEXT developing a solution to this problem 
from the start.  Now, here's yet another reason.

As much as it would appear that adding a X.509/CA-derived mechanism 
would redundantly add to the already existing DNS mechanisms ad DNS 
admin would have, adding a DNS-based update mechanism would add to 
the exiting SysAdmin mechanisms a Systems admin would have.

Reading through this thread adds even more to the reasons why I think 
this topic is a non-starter.  At first was that this proposal 
effectively extends the key effectivity period of the zone keys 
beyond the DNS need for it.  Now I see the impracticality of having 
remote machines having to navigate a variety of network security 
obstacles (such as firewalls) to phone home for security data.  I'm 
not encouraged.

More over, when it comes to something as sensitive to security, I'd 
rather have the configuration done on the in-office desk (or in a 
staging area within our own data center, etc.) of an admin than in 
remote rackspace, with or without remote hands involved.  This is a 
general rule, I am not running an operations/security team.  Once on 
the desk, normal sysadmin tools and techniques apply.

(We have had our share of customs issues shipping equipment we built 
locally and then deployed remotely.  That's another issue.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

With a week old newborn at home, I've discovered that the only 
difference between him and me is that I have to go to work daily. 
That's not fair!  Ma!

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 26 Jan 2011 11:27:04 -0500

Paul Wouters wrote:
> be using Godaddy today.

You have to make a leap-of-faith decision somewhere somehow.

I bet your leap-of-faith decision for current for current DNSSEC root 
keys is based more on what you know about current IANA than anything 
about Godaddy.

For your product family design, you seek a leap-of-faith decision now, 
valid for decades.

Why don't you put a leap-of-faith pushbutton command in the firmware 
today, so that the leap-of-faith decision can be re-made independently 
by your grand-children when he puts the unit back on the network?

Isn't this discussion running into circles?

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691

---

From: Tony Finch <[email-masked]>
Date: Wed, 26 Jan 2011 16:42:42 +0000

On Wed, 26 Jan 2011, Edward Lewis wrote:
>
> More over, when it comes to something as sensitive to security, I'd rather
> have the configuration done on the in-office desk (or in a staging area within
> our own data center, etc.) of an admin than in remote rackspace, with or
> without remote hands involved.  This is a general rule, I am not running an
> operations/security team.  Once on the desk, normal sysadmin tools and
> techniques apply.

What if the validator is in a consumer DSL router?

Tony.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 Jan 2011 12:04:06 -0500

>What if the validator is in a consumer DSL router?

We don't (and no one I ever worked for) run those.  (Meaning, I can't 
speak from experience.)  I would guess the upgrade would be done the 
way any of those are upgraded for other reasons.  (I.e, the DNSSEC 
key isn't that special.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 26 Jan 2011 12:41:45 -0500

On Wed, Jan 26, 2011 at 10:06 AM, Paul Wouters <[email-masked]> wrote:

>> If you want to perform long term trust root management, use an
>> architecture that is designed for that purpose.
>>
> time in the future? Do we just have to trust all 1500+ commercial CA? And
> deal with all the revocations? And how to install new ones, using

Use a Quorate Root then.

Multiple Signers, are recognized. A valid key must be counter signed by a
quorum of the recognized signers.

This approach is unencumbered as far as I know (Phil Z. described it at
length but did not deploy code).

As Ed Lewis points out, these are really tricky trust problems and there are
good reasons not to want to trust any monolithic single rooted scheme.

There are much larger International IT efforts than DNSSEC that have
collapsed due to failure to agree on this type of issue.

-- 
Website: http://hallambaker.com/

---

From: Brian Dickson <[email-masked]>
Date: Wed, 26 Jan 2011 13:54:12 -0400

Actually, this is only a problem if the revoked keys are removed from
the root DNSKEY RRset.

Other than space reasons, I don't see any particular reason to remove
revoked keys, especially at the root.

Perhaps someone from ICANN/IANA can answer this concern?

Joe?

Brian

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Jan 2011 13:05:17 -0500 (EST)

On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote:

> time in the future? Do we just have to trust all 1500+ commercial CA? And deal with all the revocations? And how to install new ones, using

> Use a Quorate Root then.
> 
> Multiple Signers, are recognized. A valid key must be counter signed by a quorum of the recognized signers.

Maybe we can add even more complexity to this?

The path here is extremely clear. It hopes from a common trusted key to new keys via intermediate steps,
all of which are signed. To bring in any other outside trusted third party with its own pletora of
trust anchor update issues is not solving the problem. You are just moving the problem. Worse, you are
moving the problem away from the original trusted parties into a hypothetical bag of other trusted parties
with even less clear mandates.

> As Ed Lewis points out, these are really tricky trust problems and there are good reasons not to want to trust any monolithic single rooted scheme. 

Please either specifically mention the reasons, or stop waiving your generalities. DNSSEC is already
trusting "monolithic single rooted scheme", so suggesting we destroy that is moot. There is no valid
reason to bring in third parties. Let alone insist that validating resolvers need to gain ASN.1 parsers
and X.509 trust anchors. Seriously, grab a 10 year old browser and tell me how well this "proven technology"
works? How many of those CA's are still valid today? How could we have guaranteed to have picked one that
is still active today - provided there is any?

We already have a fully functional path of trust, from root key to root key, that is validatable by DNSSEC.

> There are much larger International IT efforts than DNSSEC that have collapsed due to failure to agree on this type of issue. 

Yeah, the Government of Canada's Entrust X.509 scheme comes to mind.......

Paul

---

From: Alex Nicoll <[email-masked]>
Date: Wed, 26 Jan 2011 13:09:40 -0500

Gents (and lurking ladies) - 

Maybe I'm missing something here, but I thought that the whole purpose of DNSKEY rotation was to adhere to the basic cryptography tenet that a key is only good for so long, and then there's too great a risk of someone cracking it.  If we implement an entire schema for historical keys that chains trust, don't we introduce the capability for long term key attacks to compromise the whole system?  I know I could do this for several know encryption schemes now - there's no reason advances in computing power cannot do it for new ones.  

Long story short - wouldn't this shoot us in the foot?

-Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Wouters
Sent: Wednesday, January 26, 2011 1:05 PM
To: Phillip Hallam-Baker
Cc: Paul Hoffman; [email-masked]
Subject: Re: [dnsext] historal root keys for upgrade path?

On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote:

> what trust? And remember, this is a switch or router, not a browser or an OS with the "update now" button.

The path here is extremely clear. It hopes from a common trusted key to new keys via intermediate steps, all of which are signed. To bring in any other outside trusted third party with its own pletora of trust anchor update issues is not solving the problem. You are just moving the problem. Worse, you are moving the problem away from the original trusted parties into a hypothetical bag of other trusted parties with even less clear mandates.

> As Ed Lewis points out, these are really tricky trust problems and 
> there are good reasons not to want to trust any monolithic single rooted scheme.

Please either specifically mention the reasons, or stop waiving your generalities. DNSSEC is already trusting "monolithic single rooted scheme", so suggesting we destroy that is moot. There is no valid reason to bring in third parties. Let alone insist that validating resolvers need to gain ASN.1 parsers and X.509 trust anchors. Seriously, grab a 10 year old browser and tell me how well this "proven technology"
works? How many of those CA's are still valid today? How could we have guaranteed to have picked one that is still active today - provided there is any?

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 26 Jan 2011 13:34:22 -0500

Paul, you came here with an assertion that you were interested in solving a
particular problem.

Since then you have changed the problem whenever people suggest an
alternative that does not match your proposed solution.

PKI is complex because the world is complex. And people who try to ignore
the complexity of the real world tend to end up wit PKIs that are even more
complex than they need to be.

If I was a major router manufacturer or any other manufacturer, I would make
sure that there was satisfactory control of the ultimate root of trust
embedded in my products.

As the Internet matures and the need to upgrade equipment for purely
performance issues subsides, service lifetimes for network infrastructure is
going to be measured in decades. Which is something of a problem in an
industry where Internet time turned out to mean that Netscape took a little
over five years to go from startup, to industry behemoth, to extinction
rather than the 80-90 years that it took General Motors to achieve the same.

On Wed, Jan 26, 2011 at 1:05 PM, Paul Wouters <[email-masked]> wrote:

> moving the problem away from the original trusted parties into a
> hypothetical bag of other trusted parties
>  As Ed Lewis points out, these are really tricky trust problems and there
>> are good reasons not to want to trust any monolithic single rooted scheme.
>>
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 26 Jan 2011 16:41:15 -0500 (EST)

On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote:

> Paul, you came here with an assertion that you were interested in solving a particular problem.
> Since then you have changed the problem whenever people suggest an alternative that does not match your
> proposed solution.

> If I was a major router manufacturer or any other manufacturer, I would make sure that there was satisfactory
> control of the ultimate root of trust embedded in my products.

This particular big router vendor has stated to me that using X.509 and CA's can not
be part of the solution, exactly for the reasons I have mentioned in previous emails.

These are their words exactly:

    Frankly, one of the most compelling reasons for wanting to see
    ubiquitous DNSSEC is precisely this long, ever changing list of X.509
    CAs, each with its own policies, procedures, personnel, and pressure
    points, and each representing an opportunity for total failure of the
    whole PKI. X.509 as deployed is a security disaster, and I see
    basically no chance of it ever getting better.

    Personally, and I'm hoping to convince [vendor] and everybody else of
    this eventually, I would like to see DNSSEC *replace* X.509 as the
    PKI for basically everything on the Internet, or at least see all
    X.509 trust conditioned on DNSSEC trust.

Phillip, it is not just me. Your PKI solution does not fit this
problem. It just creates an additional problem.

> As the Internet matures and the need to upgrade equipment for purely performance issues subsides, service
> lifetimes for network infrastructure is going to be measured in decades. Which is something of a problem in
> an industry where Internet time turned out to mean that Netscape took a little over five years to go from
> startup, to industry behemoth, to extinction rather than the 80-90 years that it took General Motors to
> achieve the same.

You never did give me your professional expert estimate of the amount or
percentage of valid CA's of the latest Netscape Navigator/Communicator
released. I would still be interested in that number to confirm or deny
the usability of Certificate Agencies over a decade long deployment.

Paul

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Wed, 26 Jan 2011 15:02:14 -0700

Paul,

This does not appear to be DNS problem. Software becomes old and
insecure as time passes. Trust anchors expires, bugs are being found,
algorithms are being retired, etc. I'm assuming that the vendor already
have a secure mechanism in place to distribute software updates. Why can
you not use the same method for new trust anchors?

Thanks /Stephan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Wouters
Sent: Wednesday, January 26, 2011 3:41 PM
To: Phillip Hallam-Baker
Cc: Paul Hoffman; [email-masked]
Subject: Re: [dnsext] historal root keys for upgrade path?

> Since then you have changed the problem whenever people suggest an
alternative that does not match your

> If I was a major router manufacturer or any other manufacturer, I
would make sure that there was satisfactory
> control of the ultimate root of trust embedded in my products.

This particular big router vendor has stated to me that using X.509 and
CA's can not
be part of the solution, exactly for the reasons I have mentioned in
previous emails.

    Frankly, one of the most compelling reasons for wanting to see
    ubiquitous DNSSEC is precisely this long, ever changing list of
X.509
    CAs, each with its own policies, procedures, personnel, and pressure
    points, and each representing an opportunity for total failure of
the
    whole PKI. X.509 as deployed is a security disaster, and I see
    basically no chance of it ever getting better.

    Personally, and I'm hoping to convince [vendor] and everybody else
of
    this eventually, I would like to see DNSSEC *replace* X.509 as the
    PKI for basically everything on the Internet, or at least see all
    X.509 trust conditioned on DNSSEC trust.

> As the Internet matures and the need to upgrade equipment for purely
performance issues subsides, service
> lifetimes for network infrastructure is going to be measured in
decades. Which is something of a problem in

Paul

---

From: Joe Abley <[email-masked]>
Date: Wed, 26 Jan 2011 18:26:54 -0500

> root private keys once they are retired...

They still get published in the xml file we host at https://data.iana.org/root-anchors/, but with appropriate validFrom and validUntil attributes on the KeyDigest element to indicate that they are not current.

See

  http://tools.ietf.org/html/draft-jabley-dnssec-trust-anchor-00

which Jakob and I will pick back up shortly, sorry for the delay. Wouter's earlier proposal which is mentioned elsewhere in this thread had the principle defect that its use relied upon trusting signatures made by old keys, which in general some of us thought was a poor idea (e.g. in the event that a key was rolled because it was compromised).

Joe

---

From: Florian Weimer <[email-masked]>
Date: Thu, 27 Jan 2011 12:23:42 +0000

> have happened and the RFC5011 bit/key has been retired.

AFAUI, this is not something that can be tested in a realistic
scenario.  Any implementation will be in SDI-land, so it's not worth
bothering from an engineering point of view.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 27 Jan 2011 16:17:21 +0100

On 25 jan 2011, at 20.23, Paul Hoffman wrote:

> Bootstrapping is hard, but once you have done it, you can reuse the trust logic you used to do it again.

Unbound [1] has a very elaborate way (see the source code [2] of unbound-anchor) of maintaining the root trust anchor.

	jakob

[1] http://www.unbound.net/documentation/unbound-anchor.html
[2] http://unbound.nlnetlabs.nl/svn/trunk/smallapp/unbound-anchor.c

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Jan 2011 10:37:57 -0500 (EST)

> Unbound [1] has a very elaborate way (see the source code [2] of unbound-anchor) of maintaining the root trust anchor.

But that has the same issues we discussed earlier,

 	"You  can update it by fetching  it  from  https://data.iana.org/root-anchors/icannbun-dle.pem  (and  validate  it)."

Note the possibly human action of "and validate it"

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 27 Jan 2011 08:07:00 -0800

> Note the possibly human action of "and validate it"

Stupid question: What is wrong with the proposals where there is just a historical record of key signing by default, and the URL above as a backup?

Lets face it, 98% of the root key rollovers are going to be benign, on that once-a-year schedule.

So in those cases there actually is no security implications for those resolvers who have been offline for >1 year to just fetch the chain through DNS, start with the most recent root key they have, and follow the chain to the current root key.

On the 1% chance that its due to a compromise, there is going to be such out-of-band chatter that anyone getting it from https://data.iana.org/root-anchors/icannbun-dle.pem is GOING to be validated because everyone and his mother will have the SHA hash for this.  Yes, we need to consider 1% cases, but 1% cases do enable human-in-the-loop.

And on the 1% chance its due to someone coming up with a practical quantum computer, I think this means that all public key right now is fubared anyway, so its back-to-the-drawing-board for DNSSEC anyway.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Jan 2011 11:10:34 -0500

Both your reply and the reply from the big router vendor make it clear to me
that you do simply do not understand my proposal.

There are some cases in which it is acceptable to have anonymous
contributions like this. But in my view big router manufacturers are quite
capable of representing themselves directly in IETF and should not have need
of intermediaries.

Please tell your associate that if this is an issue, they should participate
in the group directly.

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 27 Jan 2011 08:14:21 -0800

> have happened and the RFC5011 bit/key has been retired.

Just upgrade the router firmware using the local network or a USB drive.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Jan 2011 12:02:20 -0500

[apols for top posting, referring to multiple posts here]

Good cryptographic practice depends on the resources you have available and
the algorithms involved. It is important to carry out a risk assessment for
the specific instance.

There are two considerations here, one is the risk of a cryptographic
compromise due to a cryptanalytic attack, compromise of keying material etc,
the second is the risk of failure due to operational errors, either at the
root or in infrastructure that depends on the root.

The ICANN DNS root management processes are modelled on a set of practices
that have been in use in the NSA and other places for forty years. As such,
the risk of compromise is negligible. But the risk that the operational
constraints imposed are going to prove impractical is significant.

Back in the 1980s, all the algorithms we had available were suspect at best
or known to be marginal with respect to the computing hardware that was
emerging. So limiting the cryptoperiod was very important. We knew that
breaking RSA1024 was not going to be cost effective, we had no assurance
that it would be impossible.

So in the 1980s, refreshing keying material on a regular basis was essential
even though we understood that the refresh mechanism would necessarily
introduce a vulnerability. In the 1990s, that tradeoff started to become
more marginal and today we have algorithms such as AES and RSA2048 and ECC
that make the risk of cryptanalysis insignificant compared to the risk of
operational compromise.

In this case rekey at the root raises two sets of operational concerns, the
first is for ICANN and its contractors, the second is for relying parties.

ICANN is a single point of failure but it can pour resources into the
problem of providing security. They use offline hardware that never touches
a network, they have tier6 physical security, they have key splitting etc.
etc.

We really should not need to worry about the risk of technical compromise of
an offline key with a lifetime of 20 years that is used to sign the root
KSKs once a year.

There is a significant political concern that might well cause people to ask
if we would want to rely on a single 20 year embedded key held by a
corporation that we cannot necessarily rely on being around in 20 years
time.

Back in 1995 I would have thought it inconceivable that Lotus would be
acquired by IBM in a hostile takeover or that Digital would be acquired by
Compaq. I have seen several non-profits and not-for-profits morph from being
voluntary organizations for the public good to commercial competitors and
one has become a public company.

We have also seen recently a situation where the staff of a public CA was
given the choice of issuing a known fraudulent certificate or going to jail.

The only protection that an organization can obtain that prevents that type
of coercion is to establish a technical infrastructure that makes that type
of coercion pointless.

Limiting the validity period of the root keys to a year and not having a
master root would appear to me to be a reasonable personal security
control.

So I think that if people did want a 20 year root, they would have to look
to more than one party to be the signer. Otherwise the risk of being coerced
would be unacceptably high.

On Wed, Jan 26, 2011 at 1:09 PM, Alex Nicoll <[email-masked]> wrote:

> Maybe I'm missing something here, but I thought that the whole purpose of
> DNSKEY rotation was to adhere to the basic cryptography tenet that a key is
> only good for so long, and then there's too great a risk of someone cracking
> it.  If we implement an entire schema for historical keys that chains trust,
> don't we introduce the capability for long term key attacks to compromise
> the whole system?  I know I could do this for several know encryption
> schemes now - there's no reason advances in computing power cannot do it for
> new ones.
>
> The path here is extremely clear. It hopes from a common trusted key to new
> keys via intermediate steps, all of which are signed. To bring in any other
> outside trusted third party with its own pletora of trust anchor update
> issues is not solving the problem. You are just moving the problem. Worse,
> you are moving the problem away from the original trusted parties into a
> hypothetical bag of other trusted parties with even less clear mandates.
>
> Please either specifically mention the reasons, or stop waiving your
> generalities. DNSSEC is already trusting "monolithic single rooted scheme",
> so suggesting we destroy that is moot. There is no valid reason to bring in
> third parties. Let alone insist that validating resolvers need to gain ASN.1
> parsers and X.509 trust anchors. Seriously, grab a 10 year old browser and
> tell me how well this "proven technology"
> works? How many of those CA's are still valid today? How could we have
> guaranteed to have picked one that is still active today - provided there is
> any?
>

---

From: Florian Weimer <[email-masked]>
Date: Thu, 27 Jan 2011 17:18:05 +0000

* Paul Wouters:

> Remember this has to work on a product that has just been factory
> defaulted to a config from 10 years ago, and the device is EOL with
> no firmware upgrades.

Why?  Where does this requirement come from?

---

From: Florian Weimer <[email-masked]>
Date: Thu, 27 Jan 2011 17:21:31 +0000

> on that once-a-year schedule.

I'm pretty sure that the first scheduled root KSK rollover will be
indefinitely postponed in 2014. 8-)

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Jan 2011 12:46:58 -0500 (EST)

> Why?  Where does this requirement come from?

It was an example.

The (perhaps implicit) requirement is that a device has no unneccessary
limitations that it becomes unusable at a specific expiry date within
a time period where the hardware and software is expected to still be
fully functional.

If a device becomes obsolete because the world has moved into unpredicted
direction the vendor could not forsee, that is acceptable. However, producing
equipment that you know is going to fail on a certain date only three years
into the future is most probably not.

Paul

---

From: Brian Dickson <[email-masked]>
Date: Thu, 27 Jan 2011 13:49:18 -0400

> Why?  Where does this requirement come from?

Operational reality...

There are two resource issues.

One is network engineers who are DNSSEC-knowledgeable.
(In numbers, routers >> managed customers >> noc staff >> network
engineers >> DNS network engineers >> DNSSEC network engineers.)

The other is the life of a "factory default config".

It goes from $vendor, to $flash-vendor, to $mfg, to $shipping, to
$customs, to $distributor, to $customer.
In some cases, $customer has a large inventory, to supply their $end-customers.
And in some cases, $end-customer has both a live router, and cold
spare (in a box), purchased at the same time. Think MTBF...

So, there are cases where both large numbers of $customer get a new
box, which has a slightly-outdated trust anchor (because roll-over
happened during the supply chain process), and where moderate numbers
of $customer eventually have a "new" box which is quite old.

Solving for one solves for both, ideally.

Regardless of oversimplification, having $vendor ship all routers with
DNSSEC not only supported, but enabled by default, should be
commended.

We complain about adoption delays. This, we should be falling over
ourselves to assist on, or never, ever complain again about adoption.
Seriously.

Brian

---

From: Joe Abley <[email-masked]>
Date: Thu, 27 Jan 2011 13:28:26 -0500

> Lets face it, 98% of the root key rollovers are going to be benign, on that once-a-year schedule.

There is no established schedule for rolling the root zone's KSK. All we have said to date is that we don't expect to do it any time soon, because it's not clear that support for automated handling of such an event is well-deployed in clients.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 Jan 2011 18:51:56 +0000

> From: Florian Weimer <[email-masked]>
> Date: Thu, 27 Jan 2011 17:21:31 +0000
> 

agreed, this seems likely, though undesireable.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 Jan 2011 19:03:40 +0000

> From: Joe Abley <[email-masked]>
> Date: Thu, 27 Jan 2011 13:28:26 -0500
> 
> There is no established schedule for rolling the root zone's KSK. All
> we have said to date is that we don't expect to do it any time soon,
> because it's not clear that support for automated handling of such an
> event is well-deployed in clients.

under what conditions can you imagine that changing?

(for me it's the null set.)

---

From: Brian Dickson <[email-masked]>
Date: Thu, 27 Jan 2011 15:05:38 -0400

> ourselves to assist on, or never, ever complain again about adoption.

/*  *mouth = money */

Open question, to whoever feels like answering it:
Would the following, as a general mechanism for publishing someone
else's DNSKEY (securely) work?
(Here, "foreign" means, we don't hold the private keys)

(1) Using a current, known-good trust anchor, retrieve and validate
the (foreign) DNSKEY data (possibly plural).
(2) For every algorithm in the set of foreign DNSKEY data :
(2a) Generate (one time only!!!)  a new public/private key pair for
our own (local) DNSKEY
(2b) Combine the local and foreign DNSKEY data into the apex of our
own zone file, for which we are authoritative.
(2c) Sign the DNSKEYs with our private keys
(2d) RRSIGs signed by our DNSKEYs are the only RRSIGs, and there is
one for every DNSKEY algorithm present, so even "strict" validators
should be happy
(3) Provide our (permanent) public keys as trust anchors, to whoever
will use our zone as a "bootstrap" for the foreign (possibly changing)
DNSKEYs.
(4) As necessary, i.e. whenever any foreign DNSKEY needs to be
updated, added/deleted, make corresponding adds/changes to our DNSKEY
set, and re-sign the RRSET

NB - the same foreign DNSKEYs can be kept in multiple zones, so that
specific instance usage can be tracked over time.

E.g. over time, the set of algorithms required by the foreign keys may
change, and rather than continue to sign with a superset of
historically-used algorithms,  newer instances of the zone get signed
only with new local DNSKEYs for the current algorithms. Older zone
instances continue being signed with the older keys/algorithms, so
there could be a weakness related to use of them, but that would be
limited to clients with old keys, which would expect to tail off over
time (drastically, perhaps).

These zones would be used only for bootstrapping DNSKEY data used for
"real" trust anchors, and could be discarded once the "real" trust
anchor has been validated (and *only* then).

The bootstrap process would need to rely on DNSSEC-unknown
(unvalidated) data, to reach the trust-anchored zone, but the fact
that the zone is signed with the trust anchor itself, provides
"enough" security to be considered "secure", IMHO.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Thu, 27 Jan 2011 15:11:47 -0400

> DNSSEC not only supported, but enabled by default, should be

BTW, the reason we should consider this a really big win, is the
following observation for use cases:

(1) $Enterprise deploys new $router or $switch in their infrastructure
(2) $router/$switch has DNSSEC configured on by default, and
presumably successfully bootstraps its valid root trust anchor
(3) $Enterprise configures DHCP on $router/$switch, using
$router/$switch as the validating (non-stub?) resolver
(4) $Enterprise desktops use physically-secure infrastructure to the
resolver, which does validated DNSSEC resolution. Note that $desktop
does not strictly need DNSSEC.
(5) #WIN

Brian

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Jan 2011 15:24:10 -0500 (EST)

> (2c) Sign the DNSKEYs with our private keys

Now you have just moved the problem. I need this DNSKEY as trust anchor. How
do I know this will not be rolled and how to I get historic data on this key.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Jan 2011 15:34:04 -0500

> agreed, this seems likely, though undesireable.

Why undesirable?

If the root KSK is compromised the consequences will be exhausted long
before the scheduled rollover occurs. People would be required to get on
planes and roll a new root.

DNSSEC keys are not designed to support encryption of stored data,
non-repudiation or other requirements that would normally motivate rolling
the root key.

The only possible motivation for rolling the DNSSEC root KSK would be to
limit the length of time that an attacker had to work on the problem. That
really does not make much sense unless the period between rolls is short
with respect to improvements in hardware.

Currently Moores law and the expansion of the net mean that computing
resources available to an attacker approximately double year on year (more
machines plus faster machines).

So after 4 years a cracking effort should be proceeding at 8 times the rate
it did in the first year and the contribution to the effort from the first
year represents only 1/15th = 6.7% of the cumulative effort.

If the cracking goes on another year, the contribution from the first year
is only 3% and will continue to diminish exponentially.

It follows that if you are going to mount an attack using a botnet or pooled
resources, there is really little point in attempting any effort that you do
not expect to finish within 4-6 years.

If you have a key that you expect will take 4 years to break (accounting for
improvements in speed) and start on 1 Jan 2011, you would expect to finish 1
Jan 2015. If you decide to delay your start by a year to 1 Jan 2012, the
expected end date would be some time in Feb 2015

So a policy that requires rolls at 4 year increments would appear to offer
no additional security over a policy to never roll the keys at all unless
the security of the algorithm itself was in question.

[Obviously people can argue that the increase in resources is faster or
slower than doubling each year, but we know Moore's law is 18 months and we
know that social networks get bigger so I think my figures are probably
conservative here]

---

From: Brian Dickson <[email-masked]>
Date: Thu, 27 Jan 2011 16:37:13 -0400

> do I know this will not be rolled and how to I get historic data on this

Sorry, I thought that was obvious... This DNS zone (or these zones)
would need to be maintained, actively, by $vendor.

The vendor is then responsible for the key not rolling, and the
accuracy of the served trust anchor data (root keys) in the zone, the
serving (or outsourcing the serving) of the zone, etc.

The only traffic to this zone will be bootstrapping devices, and
ideally just once per device.

The zones can be fed by a private master, and served literally from
anywhere the vendor wants.

The liability issues are strictly with the vendor to the itself (and
its customers), i.e. negligible.

It scales reasonably well, and the overhead, in terms of operational
management, while important to get right, is really insignificant.

Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Jan 2011 15:59:54 -0500

Or alternatively, the vendors get together as a consortium and set up some
infrastructure whereby they manage this in a practical manner.

This is an important problem that is not limited to DNS trust roots.

But the people who would be interested in a solution are going to be the
type of people who consider real world business issues of the type that
cause many people on this list to stick their fingers in their ears and
chant 'la-la-la not listening'.

So it is really not a problem that I think is useful to address as part of a
DNSSEC infrastructure consideration.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Jan 2011 16:01:41 -0500 (EST)

> would need to be maintained, actively, by $vendor.

The idea (or hope) was that we could do something once, instead of each vendor
having to do it for themselves. also if vendors die or merge, these zones could
die while the equipment is otherwise still fine to use.

If the vendor is active and alive and the product not EOL, then you could just
integrate it with a firmware ugprade (though this might be hard in the field)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Jan 2011 16:05:54 -0500 (EST)

On Thu, 27 Jan 2011, Phillip Hallam-Baker wrote:

> But the people who would be interested in a solution are going to be the type of people who consider real world business issues of the type that cause
> many people on this list to stick their fingers in their ears and chant 'la-la-la not listening'. 

Just because someone disagrees with you, does not mean they are not listening.

One could also argue that it has been stated repeatedly by many here
that mixing up DNSSEC and PKIX trustanchors is not desirable - yet you
keep proposing it for everything.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 27 Jan 2011 16:22:35 -0500

[moderation note]

Colleagues,

Not to pick on Paul and Phillip, but I note that some of the
discussion around this issue is a little heated sometimes.  It's an
important issue, I think we can agree, and therefore it is important
we find workable solutions (either in-protocol or out).  So let's keep
the discourse super-civilized, please.  Thanks!

A

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

---

From: Joe Abley <[email-masked]>
Date: Thu, 27 Jan 2011 16:38:10 -0500

> under what conditions can you imagine that changing?

If the groundwork was done and it looked like the client population was likely to be substantially KSK-roll-tolerant (by which I intend to imply experimentation, real-world surveys and testing, conversations with relevant vendors, a much clearer specification for desired client behaviour, etc) I would advocate scheduled KSK rolls for the root.

The benefits of all that work would be operational rather than cryptographic (at least, I have been told that there is little cryptographic in rolling an uncompromised 2048 bit root zone KSK). For example, clients are far more likely to be able to survive an emergency key roll if we know that all the code points associated with a scheduled key roll are well-understood and exercised; those from IANA and the community who are involved in managing the KSK have a better shot of getting it right if the processes involved are regularly used (even if they're not used very often).

Without a much better understanding of the likely impact on clients, however, and without any confidence that clients will handle the event without helpdesk intervention, the costs of a KSK roll appear to outweigh the benefits, even with the relatively small validating base we might imagine exists today.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Jan 2011 18:23:01 -0500

The risk of doing such a roll would be that the ensuing chaos is then used
as proof that DNSSEC is not ready for prime-time.

I do think that it is worth people like myself who have been considering
cyber-conflict issues for some time war-gaming an emergency roll. But we are
talking about possibilities that are really very unlikely indeed and we are
probably talking about scenarios that involve 'kinetic' attacks in addition
to purely cyber.

If you want to engage in that type of exercise you need to posit a plausible
scenario that would cause the emergency roll to be required.

And once you start considering those type of scenarios we are talking about
catastrophic failures that are going to completely invalidate any experience
from the proposed fire-drill.

Airlines do train for evacuation of passengers from aircraft, but they do
not perform such drills on a regular basis with paying passengers (liners on
the other hand do).

So the downside risk is large, if you try that test it is likely to damage
prospects for DNSSEC deployment. The benefit is negligible.

On Thu, Jan 27, 2011 at 4:38 PM, Joe Abley <[email-masked]> wrote:

> If the groundwork was done and it looked like the client population was
> likely to be substantially KSK-roll-tolerant (by which I intend to imply
> experimentation, real-world surveys and testing, conversations with relevant
> vendors, a much clearer specification for desired client behaviour, etc) I
> would advocate scheduled KSK rolls for the root.
>
> The benefits of all that work would be operational rather than
> cryptographic (at least, I have been told that there is little cryptographic
> in rolling an uncompromised 2048 bit root zone KSK). For example, clients
> are far more likely to be able to survive an emergency key roll if we know
> that all the code points associated with a scheduled key roll are
> well-understood and exercised; those from IANA and the community who are
> involved in managing the KSK have a better shot of getting it right if the
> processes involved are regularly used (even if they're not used very often).
>
> Without a much better understanding of the likely impact on clients,
> however, and without any confidence that clients will handle the event
> without helpdesk intervention, the costs of a KSK roll appear to outweigh
> the benefits, even with the relatively small validating base we might
> imagine exists today.
>
>
> Joe
>

---

From: David Conrad <[email-masked]>
Date: Thu, 27 Jan 2011 22:06:07 -0800

On Jan 26, 2011, at 1:26 PM, Joe Abley wrote:
> Wouter's earlier proposal which is mentioned elsewhere in this thread had the principle defect that its use relied upon trusting signatures made by old keys, which in general some of us thought was a poor idea (e.g. in the event that a key was rolled because it was compromised).

I don't think that's a risk. If a key is rolled because of a known compromise, it simply means you can't safely chain from the old-but-installed-key to the current-but-not-yet-installed key.  Presumably, when a key is known to be compromised, the chain from old to current keys would be broken such that automated systems would require human intervention.

As far as I can tell the real risk is that an attacker has an increased amount of time to secretly compromise any key in the old to current chain, thereby enabling a MITM attack to insert a branch to a new chain that will end in a malicious key.  The continued use of the old keys for something valuable means the keys have to be much stronger and it sort of defeats the purpose of scheduled rolling of keys.

Regards,
-drc

---

From: Florian Weimer <[email-masked]>
Date: Fri, 28 Jan 2011 08:21:24 +0000

* Joe Abley:

> There is no established schedule for rolling the root zone's
> KSK. All we have said to date is that we don't expect to do it any
> time soon, because it's not clear that support for automated
> handling of such an event is well-deployed in clients.

This was exactly my impression, too.  But when Nicholas brought up the
once-a-year schedule, I started looking for policy statements because
a yearly key rollover is rather scary.

The closest I could come up with is this statement:

| 6.5.  Key signing key roll-over
| 
|    Each RZ KSK will be scheduled to be rolled over through a key
|    ceremony as required, or after 5 years of operation.

<https://www.iana.org/dnssec/icann-dps.txt>

This is how I came up with the year 2014 so I didn't pull it out of
the air completely.  Of course, I welcome if you want to make it 2011
instead of 2014.

---

From: Joe Abley <[email-masked]>
Date: Fri, 28 Jan 2011 09:35:00 -0500

On 2011-01-27, at 18:23, Phillip Hallam-Baker wrote:

> The risk of doing such a roll would be that the ensuing chaos is then used as proof that DNSSEC is not ready for prime-time.

That is indeed a risk, and to confirm I am not in favour of rolling it speculatively or without extensive successful prior experimentation and testing.

A benefit of a successful, controlled roll is that we could perhaps worry less about widespread failure in the event that we need to do an emergency roll.

I'll note that this is probably not the list to debate these things.

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 28 Jan 2011 09:37:59 -0500

> I don't think that's a risk. If a key is rolled because of a known compromise, it simply means you can't safely chain from the old-but-installed-key to the current-but-not-yet-installed key.  Presu…

That's not what the trust-history proposal was about; in that proposal every outgoing key would be used to sign a copy of its subsequent incoming key, such that any validator coming on-line from a long time in the dark would have a path to the current key, no matter what key it was using before.

Downloading the trust anchor from the XML file and finding a way to trust it does not involve signatures made by previously-used KSKs, however.

Joe

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 28 Jan 2011 11:55:09 -0500

> I don't think that's a risk. If a key is rolled because of a known compromise, it simply means you can't safely chain from the old-but-installed-key to the current-but-not-yet-installed key.  Presu…

A known compromise might occur at T[n]-epsilon but detected at 
T[n]+delta (T[n] is the absolute time of rollover, and epsilon is less 
than previous cryptoperiod, i.e. T[n]-T[n-1]). Then, human intervention 
is pointless for systems that has been on-line (too late to do anything) 
and very much unlikely for those having been off-line during these 
troubled times.

Note that RFC5011 could have been "practiced" (by who would you guess 
... IANA) such that the next KSK is pre-announced at T[n-1]+mu (mu is 
small). If mu+epsilon<T[n]-T[n-1], then the on-line systems would 
reliably recover at T[n] without an implicit leap-of-faith. But that 
path would have made the root DNSKEY RRset larger.

(I quoted "practiced" because RFC5011 mandates specific validator 
procedures and allows various strategies for the root/island-of-trust 
zone manager.)

> As far as I can tell the real risk is that an attacker has an increased amount of time to secretly compromise any key in the old to current chain, thereby enabling a MITM attack to insert a branch…

Correct, that is a risk or concern.

As a more general observation, what is needed here, in essence, is a 
small assistance (sign current root KSK) from a public-key based 
notarization service (the foremost example of a PK scheme with long-term 
trust at the core of the mission statement).

However, neither IETF standardization activities nor organizations 
involved in the DNS root operations ever considered the PK notarization 
seriously.

Hence my general conclusion that DNSSEC validation must rely on some 
leap-of-faith somehow somewhere, like it or not. Root KSK recovery may 
require leap-of-faith. Unless the whole DNSSEC root zone management is 
revisited, which is not going to occur.

Some may not like the color of the room where the leap-of-faith occurs 
(yes, I did watch portions of the ICANN-staged ceremonies, thanks for 
the webcast, but no, I don't recall the color of the room). If there is 
more to it, the requirements should be spelled out in terms of basic 
deployment strategies for public key capabilities.

Regards,

-- 
- Thierry Moreau

Tel. +1-514-385-5691

---

From: Tony Finch <[email-masked]>
Date: Sun, 30 Jan 2011 19:36:16 +0000

On 27 Jan 2011, at 20:34, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> If the root KSK is compromised the consequences will be exhausted long before the scheduled rollover occurs. People would be required to get on planes and roll a new root.

If they implemented RFC 5011 properly there would be a pre-published standby KSK.

Also remember that loss is more likely than compromise.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Sun, 30 Jan 2011 19:45:52 +0000

> I don't think that's a risk. If a key is rolled because of a known compromise, it simply means you can't safely chain from the old-but-installed-key to the current-but-not-yet-installed key.  Presu…

If you implement RFC5011 you can maintain a chain of trust in the face of N-1 key compromises where N is the number of keys in the trust anchor.

Tony.

---

From: Joe Abley <[email-masked]>
Date: Sun, 30 Jan 2011 14:50:30 -0500

> If you implement RFC5011 you can maintain a chain of trust in the face of N-1 key compromises where N is the number of keys in the trust anchor.

I thought this whole thread was about how to handle an initial bootstrap, e.g. in a new device, in a device that has been off-line for longer than the 5011 key introduction period, or in the event that an emergency key roll results in a change in KSK without 5011 timing or publishing semantics.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 30 Jan 2011 13:56:35 -0800

On 1/30/11 11:50 AM, Joe Abley wrote:
>> On 28 Jan 2011, at 06:06, David Conrad<[email-masked]>  wrote:
>>>
>>

Joe is correct.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 31 Jan 2011 01:21:10 -0400

On Sun, Jan 30, 2011 at 5:56 PM, Paul Hoffman <[email-masked]> wrote:
>>>> I don't think that's a risk. If a key is rolled because of a known
>>>> compromise, it simply means you can't safely chain from the
>>>> old-but-installed-key to the current-but-not-yet-installed key.  Presumably,
>>>> when a key is known to be compromised, the chain from old to current keys
>>>> would be broken such that automated systems would require human
>>>> intervention.
>>>
>>> If you implement RFC5011 you can maintain a chain of trust in the face of
>>> N-1 key compromises where N is the number of keys in the trust anchor.
>>
>> I thought this whole thread was about how to handle an initial bootstrap,
>> e.g. in a new device, in a device that has been off-line for longer than the
>> 5011 key introduction period, or in the event that an emergency key roll
>> results in a change in KSK without 5011 timing or publishing semantics.
>
> Joe is correct.

Yes, but....

I think that there are two different considerations (at least):
- whatever bootstrap mechanism gets used, should be at least as secure
as 5011(of the current root or one of its predecessors) and/or as
secure as the current root
- if we presume the device will also ship with the current root key
and attempt to authenticate it, or failing that to 5011 it, in the
latter case there may be risks (known)

A bootstrap mechanism that uses only one trust anchor, will
necessarily fall in to two categories:
- the bootstrap anchor is the current root (public) key
- the bootstrap anchor is some other key

We don't know ahead of time, who might be interested in compromising
either kind of key, or why, or what resources they might have.

However, we should not assume that only one group or person has (or
will have) such intentions.

If one group is interested in compromising the root key, and they
succeed, *and* the current root key is used for the bootstrap process,
then the bootstrap process will be compromised as a side-effect, i.e.
be collateral damage. This is not good.

If a group is interested in compromising the bootstrap process, and
the bootstrap process does not rely exclusively on the current root
key, then those efforts would not have a side-effect of compromising
the root key. This is a good thing.

>From that perspective alone, there are distinct benefits to not
*exclusively* relying on the current root key for the bootstrap
process.

HOWEVER, and this is important, requiring TWO trust anchors of equal
strength (same algorithm, same number of bits) to BOTH chain-validate
the current root key properly as part of the bootstrap, where one of
those is a previous root key, has some distinct advantages:
- two keys (at least) would need to be compromised to compromise the target
- the possible compromise of a root key, followed by rolling the key,
means that the risk from following 5011 with that key, is only a
problem if the other bootstrap key is also compromised
- the value of compromising just the other bootstrap key is nearly
zero, since that is necessary but not sufficient to compromise the
target - thus limiting the value of this effort dramatically
----> having one trust anchor only (which is not based on the root
key) does NOT have this benefit
- minimizing the window of opportunity for attack (a one-time-only
affair) further limits the value, and consequently lowers the
likelihood of even an attempt being made

Because of things like Moore's law, it will make sense over time, to
not only roll keys, but algorithms too - and probably both at once
(i.e. new key using new alg). The periodicity of this can reasonably
be expected to linear, e.g. every N years, without increasing the
likelihood of brute force attacks succeeding.

By chaining both bootstrap methods, one using the current root key,
and one using a separate key, means old devices will always be *able*
to successfully bootstrap, while each new generation of gear will get
the next pair of keys in the respective chains. This means the pool of
potential targets at the generation-mark will be finite, decreasing
monotonically, and likely be a curve with a fat beginning and very
skinny tail.

While the value of breaking the current root key may be obvious, the
rolling of the key renders work towards that goal moot. The extra
cost, extremely small window, and ever-shrinking pool of targets,
makes breaking both of an old key pair nearly pointless, and doesn't
present a significant risk to old gear.

In diagram form, there would be two chained keysets:
R1->R2->R3... (root keys)
B1->B2->B3... (bootstrap keys)
Both would be of equal type (algorithm, size) and rolled on similar
periods (probably).
When gear is built, it is configured with Rn and Bm (for current n and
m, i.e. latest versions).
The current root key Rc is retrieved and validated using 5011-type
logic from Rn, and further validated using the latest signature Bc
(which is itself retrieved using 5011-type logic from Bm).
Only if all checks succeed, is Rc installed. Rn is never installed,
but only ever used for the one-time validation of Rc.

IMHO, the incremental cost of maintaining a second chain of keys is
small, especially if they are managed by the same group, and using
HSMs as is currently the case. But, I'll let those who maintain this
speak for themselves, ditto the potential clients.

And, of course, this is all for unmanaged, fire-and-forget usage. It
isn't meant to replace best practices, but rather to limit the damage
if best practices are not followed (or are unable to be comprehended).

Brian

---

From: Tony Finch <[email-masked]>
Date: Mon, 31 Jan 2011 10:41:21 +0000

On Sun, 30 Jan 2011, Joe Abley wrote:
>
> I thought this whole thread was about how to handle an initial
> bootstrap, e.g. in a new device, in a device that has been off-line for
> longer than the 5011 key introduction period, or in the event that an
> emergency key roll results in a change in KSK without 5011 timing or
> publishing semantics.

Yes, but the bootstrap problem is made much worse by the current way the
root zone uses RFC 5011 (assuming that it does in fact use RFC 5011). In
particular if you go for a very long key introduction period then you
avoid most of the horrific problems that occur for software distributed
just before a rollover, and many emergency key rollovers should be
non-events.

RFC 5011 is designed so that you can publish your next key now, though
it won't be deployed until 2014. In the event of loss or compromise of the
active key, you can rollover to the standby key without operational effect
since validators will already trust it. Software that is published just
before the rollover (and devices with embedded software) will already know
the right trust anchor to use after the rollover. Remember that "just
before" is measured in years.

The RFC 5011 add hold-down time is a minimum to mitigate some attack
scenarios. It isn't intended to be an actual pre-publication interval
used in real deployments, because if you do that the N-1 compromise
resistance is useless.

Question: Is it in fact practical to keep the standby key in a manner that
makes it unlikely to be lost or compromised when the live key is? (How do
you know you haven't lost the standby key if you never use it?!) Perhaps
it is possible to come up with a better replacement for RFC 5011, because
no longer need to worry about managing thousands of trust anchors, so we
could tolerate a more elaborate scheme for establishing trust in the one
root key.

Tony.

---

From: Joe Abley <[email-masked]>
Date: Mon, 31 Jan 2011 07:14:31 -0500

> could tolerate a more elaborate scheme for establishing trust in the one

The DNSSEC Policy and Practice Statements for the root zone have been published for a long time -- there should be no mystery here.

There is no pre-generated standby KSK for the root zone.

If there *was* one, then it would presumably be generated using separate ceremonies and stored in deliberately different places from the current one (otherwise pretty much any compromise scenario for the production KSK might also invalidate the standby key). Even then there would still be elements in common, since the same organisation would be responsible for managing both keys. As you note, there are also operational challenges in maintaining a key that is not regularly exercised.

The root zone KSK management procedures and facilities are designed to minimise the threat of compromise: there are two separate, autonomous, well-guarded and well-monitored facilities; procedures are audited; ceremonies are scrutinised; etc. The approach is intended to minimise the probability of compromise.

RFC 5011 is a mechanism for scheduled key rollovers. There is always the possibility that emergency key rollovers will happen, and that 5011 semantics (in particular the 30-day dual-publish window) might not be followed.

I think the open question is not whether we need a better mechanism to accommodate scheduled key rollovers -- the open question is how best to bootstrap a validator that (for whatever reason) has no working trust anchor installed.

Joe

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 31 Jan 2011 14:09:57 +0100

Hi Joe,

On 01/31/2011 01:14 PM, Joe Abley wrote:
> RFC 5011 is a mechanism for scheduled key rollovers. There is always
> the possibility that emergency key rollovers will happen, and that
> 5011 semantics (in particular the 30-day dual-publish window) might
> not be followed.

The approaches under discussion that I made rely on a 30-day
dual-publish window, the trust-history draft and the unbound-anchor
tool.  Because the approaches extend the 5011 mechanism with downtime
compensation.  You can see from the 5011 state why it is failing, and
30-days downtime caused it.  Increased speed for the bootstrap mechanism
would make that bootstrap mechanism less safe (because it can be used to
circumvent the 30-day timer in 5011), hence I chose to wait until 5011
is known to fail (30-days passed) so that this 'add-on' to 5011 would
not lower security.  Thus a fast rollover would break those deployments:
both 5011 and the bootstrap mechanism will fail, and the failure mode is
that the key is unchanged.  This is a feature, ... if you want software
deployed that does something else, then, it is good to have this
discussion :-)

Best regards,
   Wouter

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 31 Jan 2011 08:14:44 -0500

> likelihood of even an attempt being made

I think it would be a good idea to have a separate chain of trust in this
instance.

ICANN has reserved the right to roll the root and according to one post
requires the ability to do so at 60 days notice. To me that says that ICANN
does not want to be the ultimate root of trust for everything on the
Internet. They would be very ill advised to change that decision.

The main challenge in setting up an alternative chain would be to find a
party willing to run it that everyone involved can trust. Which is probably
impossible.

My view is that any ultimate root of trust would have to have a multiple
signer configuration and would have to be available for more than just one
technology. The cost of doing such a root right would be considerable. Using
it for DNS alone would be a waste.

Besides DNS there are many other critical roots that are at issue. Device
authentication for example, there is a similar issue with RFID.

Running such schemes becomes complicated because they end up hitting
government security concerns. If every electronic device requires an
identifier issued by a single entity under the control of one government,
other governments wonder if that might be used as a weapon in a trade
dispute.

---

From: Joe Abley <[email-masked]>
Date: Mon, 31 Jan 2011 08:24:32 -0500

On 2011-01-31, at 08:14, Phillip Hallam-Baker wrote:

> ICANN has reserved the right to roll the root and according to one post requires the ability to do so at 60 days notice.

Since we have a published DPS, let's refer to that rather than pulling numbers out of e-mail threads.

  https://www.iana.org/dnssec/icann-dps.txt

Joe

4.5.3.  Entity private key compromise procedures

4.5.3.1.  Key Signing Key compromise

   ICANN has established and maintains Emergency KSK roll-over
   procedures to ensure readiness for key compromise situations.

   Upon the suspected or known compromise of a Root Zone Key Signing
   Key, IKOS will assess the situation, develop an appropriate action
   plan, and implement the action plan with approval from the PMA and
   ICANN executive management.

   As part of the KSK emergency roll-over procedures, ICANN maintains
   the capability of being able to generate and publish an interim Trust
   Anchor within 48 hours.  In favorable circumstances, this interim
   Trust Anchor may be used to facilitate an orderly RFC 5011 [RFC5011]
   automatic KSK roll-over to a new and sanctioned Trust Anchor
   generated at a new scheduled key ceremony, held within reasonable
   time.

   ICANN will inform the community of any emergency as soon as possible
   using the channels stipulated in section 2.1.

4.5.3.2.  Key Signing Key loss

   If the private component of a Trust Anchor is permanently lost, the
   latest point in time where this loss is detected, will inevitably be
   at the key ceremony when it is supposed to be used.  At this point in
   time, the Root Zone Maintainer/ZSK Operator has signatures for at
   least 33 days (see 6.6) of independent operations.

   If possible, a new KSK will be generated at this key ceremony or
   another ceremony scheduled within 48 hours.  If ICANN is unable to
   accommodate the key ceremony, an interim KSK must be generated by
   ICANN and published as a Trust Anchor within the stipulated 48 hours.

   The community is then given a minimum of 30 days notice to add the
   new Trust Anchors to the validating resolvers before the DNSKEY RRset
   has to be re-signed with the new Trust Anchor.  Failure to update a
   validating resolver will render that resolver inoperable.

   ICANN will inform the community of any emergency as soon as possible
   using the channels stipulated in section 2.1.

   The old Trust Anchor will remain untouched in the key set for one 10
   days time slot (see section Section 6.6).  In the next consecutive
   time slot, the old Trust Anchor will be marked as revoked, and after
   this time slot the lost key is permanently removed.

4.5.3.3.  Zone Signing Key Compromise

   ICANN will support Root Zone Zone Signing Key emergency rollover in
   the case of RZ ZSK compromise while following VeriSign's procedural
   directions.  Refer to the Root Zone ZSK Operator's DPS for details.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 31 Jan 2011 14:22:29 -0400

>  https://www.iana.org/dnssec/icann-dps.txt

Thanks for pointing that out.

Having read it, it appears that any new RZ KSK is pre-published and
signed by the old KSK for about 50 days only.

After that point in time, an old trust anchor would no longer be able
to automagically validate the new KSK (5011 method).

So, it appears that an automagic bootstrap method would have to rely
on something other than the RZ KSK (or specifically its trust
anchor/public key).

The simplest bootstrap method would be to have a series of BSK
(bootstrap keys), created on a periodic basis (every N years), and
used as follows:
- keep all the keys indefinitely (e.g. until such time as it can
reasonably be expected that the vast majority of consumers of the key
have bootstrapped, or that it is unreasonable to keep a particular key
due to operational constraints.)
- sign the current RZ KSK using all the keys, with appropriate
signature intervals/durations/effort, such as annually pre-generating
M signatures with validity durations of 60 days and overlaps of 7 days
at each end
- publish the latest key and sign it along with the RZ KSK
- any one BSK would be able to validate the current RZ KSK
- any manufacturer would be able to validate the current BSK, both via
its own self-signature, and via the current RZ ZSK and standard
validation. The current RZ KSK itself can be installed/validated using
the ICANN-published procedures/mechanisms.

A slightly more secure method would involve two (or more) independent
series of such keys, but that may be overkill or too "expensive".

The number of consumers of the current key would vary (up and/or down,
as devices are manufactured and bootstrapped respectively). The number
of consumers of previous keys would be monotonically decreasing.
Bootstrap would be a one-step process (retrieve RZ KSK and validate
using the trust anchor), unless there were multiple bootstrap trust
anchors, in which case it would be an X step process (X being the
number of trust anchors installed).

Brian

---

From: Paul Wouters <[email-masked]>
Date: Mon, 31 Jan 2011 14:15:45 -0500 (EST)

> (bootstrap keys), created on a periodic basis (every N years), and

I think the simplest method is the TALINK one described in Wouter's
draft. Keep the historic 5011 information in a special zone (and ignore
the expired RRSIGs in them)

I don't think we realistically can change the current root key management.

Paul

---

From: Joe Abley <[email-masked]>
Date: Mon, 31 Jan 2011 14:20:29 -0500

> signed by the old KSK for about 50 days only.

For a scheduled KSK roll, yes. Note that that's not what we're talking about.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 31 Jan 2011 14:23:00 -0500

> (bootstrap keys), created on a periodic basis (every N years), and

If a compromise has occurred then the first thing to ask would be why.

There are only three places where a compromise can logically occur - in the
cryptographic algorithm, in the cryptographic hardware manufacturer or in
ICANN,

If its the algorithm then the whole series of BSKs is compromised.

If it is the manufacturer of the HSM, same thing.

If the issue was ICANN it is unlikely we would want to re-implement the
scheme that had failed.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 31 Jan 2011 11:31:55 -0800

> For a scheduled KSK roll, yes. Note that that's not what we're talking about.

I thought we WERE talking about for scheduled KSK rolls.

If we have either an algorithm or KSK key compromise, we have a far bigger problem and going to a more human-centric route is probably doable.

ESPECIALLY if a failure for the TALINK-like mechanism (which fails for compromise-cases) is 'do leap of faith for the root for NON-secure records', so even then the name lookups etc will still work, only cryptographic trust mechanisms built on top of DNSSEC would fail.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 31 Jan 2011 15:32:20 -0400

On Mon, Jan 31, 2011 at 3:23 PM, Phillip Hallam-Baker <[email-masked]> wrote:
>
>
> On Mon, Jan 31, 2011 at 1:22 PM, Brian Dickson

> cryptographic algorithm, in the cryptographic hardware manufacturer or in

No, there is a fourth place: brute force attack on the key/signature,
to find the key.

The brute force success on one key, compromises that key only, plus
any data signed by it or derived therefrom.

If another key of the same algorithm, held in the same hardware and
operated by the same party exists, but is not dependent upon the first
key, it remains secure.

Brian

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 31 Jan 2011 11:36:35 -0800

> any data signed by it or derived therefrom.

NO THERE IS NOT!

Repeat after me:

"If you are in even the remotest danger of a brute force attack by anything less than a cubic-earth of sci-fi nanotech, you need to use a larger key."

Cryptographic attacks may happen, which if it makes it possible to brute-force one key implies that the cryptosystem itself has broken.  

Brute force alone, outside the context of a cryptographic attack, WILL NOT HAPPEN.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 31 Jan 2011 14:37:55 -0500

> For a scheduled KSK roll, yes. Note that that's not what we're talking

That is the one that I was talking about.

If we ever got to the stage where we did an emergency roll we are in unknown
territory. Its like planning for what to do in case of civil war in the US.
So many other things would have to change before it was a possibility that
planning is futile.

ICANN can eliminate the problem of rollovers for scheduled rolls by
announcing that it will never roll the key except in an emergency.

We faced this problem in the PKI world and found that 20 year roots were a
better solution. So far the only issues caused have been due to doubts as to
the security of the cryptographic algorithm which in turn is perhaps
excusable given that the state of cryptography was not as good in the 1990s
as it is today [*]

I know that it is fashionable to roll keys every so often. But in the case
of a root key it causes more problems than it solves.

[*] Use of MD5 is discouraged for new signatures but it is not yet
compromised in a way that invalidates MD5 signed roots.
-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 31 Jan 2011 14:42:59 -0500

> No, there is a fourth place: brute force attack on the key/signature,

No, that would be a cryptographic algorithm weakness which was the first
case I gave.

---

From: Joe Abley <[email-masked]>
Date: Mon, 31 Jan 2011 15:02:55 -0500

> If we have either an algorithm or KSK key compromise, we have a far bigger problem and going to a more human-centric route is probably doable.

The problem space we're considering is that of embedded devices (think 5,000,000 deployed linksys home gateways) for which a human-centric path is effectively not an option. No?

> ESPECIALLY if a failure for the TALINK-like mechanism (which fails for compromise-cases) is 'do leap of faith for the root for NON-secure records', so even then the name lookups etc will still work…

The problem with the TALINK and similar trust-chaining proposals is that in the cases where you really need them, they can't work.

I don't think the scheme I just posted (and have described here before) is particularly elegant, but it has the benefit that it's immediately deployable and doesn't introduce any trust points into the system that aren't already there.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 31 Jan 2011 18:36:50 -0500

On Mon, Jan 31, 2011 at 3:02 PM, Joe Abley <[email-masked]> wrote:

> > If we have either an algorithm or KSK key compromise, we have a far
> bigger problem and going to a more human-centric route is probably doable.
>
> The problem space we're considering is that of embedded devices (think
> 5,000,000 deployed linksys home gateways) for which a human-centric path is
> effectively not an option. No?
>
> > ESPECIALLY if a failure for the TALINK-like mechanism (which fails for
> compromise-cases) is 'do leap of faith for the root for NON-secure records',
> so even then the name lookups etc will still work, only cryptographic trust
> mechanisms built on top of DNSSEC would fail.
>
> The problem with the TALINK and similar trust-chaining proposals is that in
> the cases where you really need them, they can't work.
>
> I don't think the scheme I just posted (and have described here before) is
> particularly elegant, but it has the benefit that it's immediately
> deployable and doesn't introduce any trust points into the system that
> aren't already there.

It does not add any trust points and it does not add any stability either.

All you are doing is sticking another turtle underneath the pile. If you
want to make a difference then you have to either decide that this is an
acceptable risk and you are not going to deal with it or you have to think
about something that isn't a turtle.

---

From: Joe Abley <[email-masked]>
Date: Mon, 31 Jan 2011 18:55:36 -0500

> It does not add any trust points and it does not add any stability either.

I'm not sure what you mean by that...

> All you are doing is sticking another turtle underneath the pile. If you want to make a difference then you have to either decide that this is an acceptable risk and you are not going to deal with it or you have to think about something that isn't a turtle.

... or by any of that, to be honest. Perhaps you could rephrase?

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 31 Jan 2011 21:23:45 -0500

The original reference was to a possibly apocryphal tale told by Bertrand
Russell in his autobiography describing the nature of infinity.

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

Regularly rolling the root does not improve security. All that is achieved
is that one point of vulnerability becomes two points until such time as the
original root is no longer trusted for ANY purpose.

If you change the management rules to require a permanent chain of roots to
be kept you have precisely the same exposure to the legacy root plus the
additional exposure incurred through establishing a second root and the
distribution mechanism.

Without wanting to put too fine a point on the matter, the only way you are
going to be able to rely on an ICANN issued root key in twenty years time is
if ICANN decides that this is something that they are going to support. And
if they did decide to offer such support there are much simpler ways to do
so than the draft proposed.

---

From: Joe Abley <[email-masked]>
Date: Mon, 31 Jan 2011 21:42:08 -0500

On 2011-01-31, at 21:23, Phillip Hallam-Baker wrote:

> Regularly rolling the root does not improve security. All that is achieved is that one point of vulnerability becomes two points until such time as the original root is no longer trusted for ANY purpose.

The draft I submitted doesn't address scheduled key rolls. Rather, it addresses the problem of how a validator establishes an initial trust anchor to be used for continuing operation.

I appreciate the distinction is muddied by the fact that a validator that fails to catch a key roll with 5011 semantics is effectively left in a state where it needs to bootstrap itself again.

> If you change the management rules to require a permanent chain of roots to be kept you have precisely the same exposure to the legacy root plus the additional exposure incurred through establishing a second root and the distribution mechanism.

Indeed. The proposal I posted doesn't establish a second root; it uses established ones.

> Without wanting to put too fine a point on the matter, the only way you are going to be able to rely on an ICANN issued root key in twenty years time is if ICANN decides that this is something that they are going to support. And if they did decide to offer such support there are much simpler ways to do so than the draft proposed.

ICANN has committed to support the current publication mechanisms for as long as they retain the role of KSK manager; it's in the IANA functions contract with NTIA (by reference). I think we can assume that the same requirement would be imposed on any new NTIA contractor in the event that some other organisation took over the role.

What support could ICANN provide that would facilitate a simpler bootstrapping method?

(The proposal Dave and I posted seemed pretty simple to me: you pull an XML document using HTTP, then the certificates referred to by that XML doc and use one of the X.509 CA keys you already have to verify any one of them. Until you find a suitable cert, you operate without DNSSEC.)

Joe

---

From: Paul Wouters <[email-masked]>
Date: Mon, 31 Jan 2011 22:22:52 -0500 (EST)

On Mon, 31 Jan 2011, Joe Abley wrote:

> The proposal I posted doesn't establish a second root; it uses established ones

I do agree you are not only adding a second root. You are potentially adding many roots
by requiring one or more PKIX Certificate Agencies.

> (The proposal Dave and I posted seemed pretty simple to me: you pull an XML document using HTTP, then the certificates referred to by that XML doc and use one of the X.509 CA keys you already have…

This of course, mixes two different trust anchor schemes. DNSSEC should not depend on PKIX.

TALINK on the other end, does not depend on PKIX.

Paul

---

From: Brian Dickson <[email-masked]>
Date: Tue, 1 Feb 2011 01:02:09 -0400

> If its the algorithm then the whole series of BSKs is compromised.

I think it is helpful to use as explicit a form of language as
necessary, to clearly communicate ideas.

So, when I ask you to clarify this into particulars, it is with the
intent of understanding what you meant.

"If a compromise has occurred" - a compromise of what, exactly, are
you talking about?

It could be that there has been a theoretical weakness in the
algorithm, which makes it slightly more feasible to break, but that
the root zone key's private parts have not been exposed.

In which case, this is "theoretically weak".

On the other hand, it could be that the root zone key has had its
private parts found, in which case the term "compromised" has the very
real, concrete meaning in that someone has directly compromised its
security.

In both cases, the impact on another key, which is neither dependent,
nor whose security depends on, the root zone key, is non-existent,
other than that it implies that the other key is equally
"theoretically weak".

In other words, the BSKs might be "weak", but not "compromised", per
se - and using that term doesn't facilitate clear and rational
discussion, of something pretty darned important for a large class of
operational problems (bootstrapping).

As to the cost of compromising multiple keys:

If two keys share only the algorithm and key size, the expected effort
for both is equal.

If the required effort to discover the private keys for either key is,
on average, what would require six months of the combined effort of
10,000,000 zombie machines, then:
- it would take a botnet of 10,000,000 machines six months (on
average) to break the root zone key
- it would also take the same botnet six months (on average) to break
any single one of the BSKs
- combined, it would take a year of the whole botnet's combined
resources to compromise one BSK and the root zone key, which would
then create a theoretical ability to forge answers to queries for both
zones, for a small number of devices during a one-time, small window
when they bootstrap
- the BSKs are independent, so for N BSKs, it would take N+1 times the
total resource requirements, to have all the BSKs compromised

I'd suggest that the very large resource requirements, the very small
window of opportunity, and the requirement that both forgery attempts
succeed, for a one-time attack on one single device, puts the
likelihood of success sufficiently close to zero to discourage anyone
or any organization from making the attempt.

Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 Feb 2011 00:59:55 -0500

> In which case, this is "theoretically weak".

This is of course possible, and something easily cured at the sub-root
level.

It is not possible to cure it at the root level unless you move to a
different key strength or more likely given the way RSA strength goes with
key size, a whole new algorithm.

> real, concrete meaning in that someone has directly compromised its

This could not happen without the cryptographic hardware being faulty or
physically compromised or the design of the system being at fault.

Competently designed HSMs do not allow their keys to be exported to just any
HSM. There is a cryptographic protocol that governs transfer of keys from
one to another.

It should take multiple failures before it was even possible to attempt such
an attack.

> other than that it implies that the other key is equally

The whole purpose of high security root key management is to ensure that
compromise is not possible without a major systemic failure.

Since both keys are managed under the same practices, a systemic fault that
affects one will affect the other.

If we compare the security of the ICANN root to the security of the British
crown jewels, the ICANN root is quite definitely more secure. In the first
place there are rather more controls that can be placed on information than
on a valuable object which must inevitably be in sole custody of a very
limited number of people from time to time. Secondly, the incentive to
default is far greater as the crown jewels would be infinitely easier to
fence.

So given that we are talking about extraordinarily low probabilities in the
first place, the concerns that dominate management of cryptographic keys at
the retail level are almost eliminated when managing a high security root
key.