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

From: Tony Finch <[email-masked]>
Date: Tue, 1 Feb 2011 19:14:59 +0000

On Mon, 31 Jan 2011, Phillip Hallam-Baker wrote:
>
> ICANN can eliminate the problem of rollovers for scheduled rolls by
> announcing that it will never roll the key except in an emergency.

The problem with that idea is that (per Cisco's plan) if every
Internet-connected device is a validator, an emergency will break the
entire Internet. You *have* to plan for root key rollovers to be normal
events that can be handled without fuss.

> We faced this problem in the PKI world and found that 20 year roots were a
> better solution.

But in the PKI world you have many trust anchors which can come and go as
time passes without breaking the whole system.

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.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Tue, 1 Feb 2011 19:33:21 +0000

On Tue, 1 Feb 2011, Phillip Hallam-Baker wrote:
>
> The whole purpose of high security root key management is to ensure that
> compromise is not possible without a major systemic failure.

If you are doing it right, you are more likely to accidentally destroy the
private key than expose it.

Tony.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 Feb 2011 15:18:06 -0500

> events that can be handled without fuss.

If you want to plan effectively for an emergency you have to do much more
than just roll the key.

The design of commercial PKI roots has been predicated on the need to make
them tamper-evident and not to eliminate the possibility  of a compromise.

If we ever did have to do an emergency roll we would probably need to change
the whole signing scheme as well. We would at a minimum need to go for a
stronger key but we might well have to go to a different algorithm.

> time passes without breaking the whole system.

Actually the number of roots is much smaller than people imagine. In the
case of Windows the ultimate root that matters is held by Microsoft and
always has been. That is the root used to sign the CTL that authorizes the
roots.

I believe that new CTL keys are introduced from time to time. But a given
root is good for the support lifetime of the product in question and in
practice has been maintained beyond that point.

And as certain people keep pointing out, as currently configured, each root
provides a fresh opportunity to compromise the system. That is the issue CAA
is designed to address.

-- 
Website: http://hallambaker.com/
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 2 Feb 2011 10:37:38 +0100

On 31 jan 2011, at 20.37, Phillip Hallam-Baker wrote:

> 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. 

I could not agree with you more - vanity key rollovers are not useful.

	jakob

---

From: Tony Finch <[email-masked]>
Date: Wed, 2 Feb 2011 14:06:58 +0000

> I could not agree with you more - vanity key rollovers are not useful.

How else can you know that a necessary rollover will work, e.g. to upgrade
the key length or algorithm or because of an emergency?

Tony.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 2 Feb 2011 15:32:16 +0100

> the key length or algorithm or because of an emergency?

I'm not saying we should not test key rollovers, but testing in public on the live Internet would, IMHO, be irresponsible. Testing should be exercised in a closed environment, together with vendors.

We don't set real buildings on fire just to make sure that the fire brigade still operates as expected - we test and exercise them under much better control.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Feb 2011 09:36:39 -0500

Unfortunately the ability to do a vanity key roll does not really help in
emergency planning.

We have many protocols that allow us to slot in new crypto but when the
pragmatics of deployment are considered they just simply don't work.

We are currently moving from 1024 bit RSA to 2048 and it is creating quite a
few issues despite the fact that almost everything that does 1024 does 2048.

The SHA-256 transition for SSL is going to be a major upheaval. MD5 to SHA1
was easy because everything supported SHA1. But only 50% of the base
supports SHA-256 if that.

---

From: Tony Finch <[email-masked]>
Date: Wed, 2 Feb 2011 14:39:10 +0000

On Wed, 2 Feb 2011, Jakob Schlyter wrote:
>
> I'm not saying we should not test key rollovers, but testing in public
> on the live Internet would, IMHO, be irresponsible. Testing should be
> exercised in a closed environment, together with vendors.

I was not thinking of bench testing, I was thinking of maintaining
the operational readiness of all the installations out there.

> We don't set real buildings on fire just to make sure that the fire
> brigade still operates as expected - we test and exercise them under
> much better control.

We do drill non-emergency evacuations and deliberately sound operational
fire alarm systems.

Tony.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Feb 2011 11:30:38 -0500

We have about a quarter billion names and in excess of four billion devices.

By the time we get to the second roll in the 2020 time frame I would expect
us to be considering about ten billion devices, most of which we would hope
to have DNSSEC capability.

If the cost of this firedrill is $0.10 cents per device we are talking about
a billion dollar fire drill. If the cost is $10 per device we have spent
$100 billion.

The reason that costs accumulate in the federal government PKI is that (1)
they hire contractors looking to inflate costs and (2) they have a heck of a
lot of devices and small administrative cost escalates quickly.

Loading up unnecessary requirements like vanity root rolls is the reason
some people's X.509 PKIs became overly complex and difficult to manage.

That is why we settled on using long term embedded roots in the SSL PKI. It
is not an ideal situation from the crypto-perfectionist point of view, but
that is not the only consideration.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Feb 2011 11:42:31 -0500

On Feb 2, 2011, at 11:30 AM, Phillip Hallam-Baker wrote:
> If the cost of this firedrill is $0.10 cents per device we are talking about a billion dollar fire drill. If the cost is $10 per device we have spent $100 billion.

There are two problems with this scare figure.   First, most devices will be online during the rollover, and will therefore handle it automatically.   The number of devices that will have to be physically touched by an administrator will be small relative to the total number of devices.   Second, if you have ten billion devices, each of which cost at least $50, then to the "you" we are talking about, a billion dollars is literally pocket change.  Because really you have a billion people with all those devices, and so the cost is more like $1 per person.

Having said that, however, it is worth noting that your scare figure is in fact valid in the event of an emergency root key rollover.   So this does argue in favor of having multiple chains of trust, so that you still have a key you can trust even if you can't trust the root key.   Granted, having extra keys like this is also dangerous, because those keys are also subject to compromise, but the cost per incident for such a compromise is much lower, and the value of such a compromise is also lower.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 2 Feb 2011 14:49:29 -0500 (EST)

On Wed, 2 Feb 2011, Phillip Hallam-Baker wrote:

> We are currently moving from 1024 bit RSA to 2048 and it is creating quite a few issues despite the fact that almost
> everything that does 1024 does 2048.

Can you name some of the "quite a few" issues? I'd be interested to hear them.

The only one that I'm aware of is using PKIX with IKE and problems with
UDP fragmentation when large PKIX blobs are sent inline with IKE. The
difference between 1024 and 2048 bit keys seemed to trigger this packet
size related issue.

Paul

---

From: Florian Weimer <[email-masked]>
Date: Fri, 04 Feb 2011 13:35:02 +0000

* Thierry Moreau:

> 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 still don't understand how you can postulate the existence of
distinct "crypto periods" when you tie them intimately by
cryptographic means (such as RFC 5011, or Wouter's trust anchor
history mechanism).

-- 
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
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext