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

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: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf Of Paul Wouters
Sent: Wednesday, January 26, 2011 1:05 PM
To: Phillip Hallam-Baker
Cc: Paul Hoffman; dnsext@ietf.org
Subject: Re: [dnsext] historal root keys for upgrade path?

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

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

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