Fw: Root Zone DNSSEC Deployment Technical Status Update

Thierry Moreau thierry.moreau at connotech.com
Fri Jul 16 13:59:41 EDT 2010


Perry E. Metzger wrote:
> The root zone has been signed, and the root zone trust anchor has
> been published.
> 

That's a great achievement for the parties involved. It is also a 
significant step towards more trustworthy DNS data.


I have been following this with attention from the perspective of 
"system-wide master key", i.e. a slightly different perspective than 
"trust anchor". The trust anchor may indeed be trusted by anyone. The 
"system-wide master key" is intended to be trustworthy to some "broadest 
extent" according to some (tacit) assessment.


Three outstanding issues on my plate:


A social engineering incident?

With what was called DURZ (Deliberately Unvalidatable Root Zone), you, 
security experts, has been trained to accept signature validation 
failures as false alarms by experts from reputable institutions. I spare 
you the details, since DURZ is now over (it may have spread to TLD 
managers though), but the formal protocol specification allows a 
compliant validator implementation to declare a signature failure with 
the DURZ as it was deployed. No specific rationale was given to me for 
the non-use of unknown/proprietary/foreign signature algorithm code(s) 
as a better interim deployment strategy.

Auditing details are not yet public.

I am wondering specifically about the protections of the private key 
material between the first "key ceremony" and the second one. I didn't 
investigate these details since ICANN was in charge and promised full 
transparency. Moreover, my critiques were kind of counterproductive in 
face of the seemingly overwhelming confidence in advice from the 
Verisign experts. In the worse scenario, we would already have a KSK 
signature key on which a "suspected breach" qualification would be attached.

Is there an emergency KSK rollover strategy?

Again, I spare you the details, but the way the RFC5011 is implemented, 
there is no automated KSK rollover strategy (this would require a larger 
set of keys at the root because a standby KSK would be needed).


Nothing above threatens the relevance, effectiveness, and benefits of 
the current deployment, unless you have a rationale risk analysis that 
convinces you that "national security" grade key management is a 
necessity. My DNSSEC root signature key risk analysis does not conclude 
that "national security" grade key management is needed for the official 
DNS root zone.

But lessons may be learned with the perspective of a rigorous security 
analysis (if we had to do some system-wide key deployment with impacts 
similar to the global DNS integrity ...). The DNSSEC protocol definition 
and root deployment project has many facets in which it was venturing 
into virgin ground (e.g. the claimed transparency for the KSK management 
procedures by ICANN).


Nobody ever done such a thing before, even less so in a production 
system with global impacts, so I give them a provisional A grade (not an 
A+) until the full auditing details are provided. But that's only me!


Regards,


-- 
- Thierry Moreau

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

Tel. +1-514-385-5691

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list