Root Zone DNSSEC Deployment Technical Status Update

[Thierry Moreau]

Dear Jakob:

Trying to reply specifically. The bigger picture would require extensive 
background explanations.

Jakob Schlyter wrote:
> On 16 jul 2010, at 19.59, Thierry Moreau wrote:
> 
>> 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.
> 
> Thierry, do you know of anyone that configured the DURZ DNSKEY and accepted the signature validation failure resulting because of this? We had good (documented) reasons for deploying the DURZ as we did, the deployment was successful and it is now all water under the bridge. Adding FUD at this time does not help.
> 

This is not the way I approach the DURZ strategy as implemented by the 
deployment team.

I am referring to a specific DNSSEC protocol provision, but I will first 
make an analogy.

You install a fire alarm system in your house (DNSSEC is an alarm system 
for bogus DNS data) but the UL certification officer didn't come yet to 
make the official approval (no trust anchor for a zone on which your 
e-banking relies). Then an alarm triggers in the night (the mob behind 
the e-banking phishers got the RRSIG wrong -- they have a learning curve 
too). You tell your relatives to stay in the house because the alarm 
system is not reliable. Oh no, you would rather play it safe! (but is 
that what your DNSSEC-aware banking application would do: avoid a 
service call to the e-banking center because you don't have a configured 
trust anchor?).

Here is the protocol provision: RFC4035 5.1 allows validators to report 
bogus (alarm signal) when encountering an unvalidatable RRsig for a zone 
without a local basis for trust anchor.

Incidentally, you say you [the design team] had good *documented* 
reasons for implementing DURZ *as*you*did*. Did you document why any of 
unknown/proprietary/foreign signature algorithm code(s) were not 
possible (this was an alternative)? This was my outstanding question.

> 
>> Auditing details are not yet public.
> 
> Yes, they are - see http://data.iana.org/ksk-ceremony/. If there is anything missing, please let me know.
> 

Thanks, great. The two key ceremony scripts are what I wanted to look at.

> 
>> 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.
> 
> The key material was couriered between the Key Management Facilities by ICANN staff members. I'd be happy to make sure you get answers to any questions you may have regarding this handling.
> 

OK. You seem to refer to courier service between East Cost Facility 
(ECF) safe #1 (closed at ceremony 1 steps 199-202 and presumably opened 
for the courier service later on), carrying Tamper Evident Bags (TEB) 
sealed at steps 194-197 (see also 80-84), and deposited in West Coast 
Facility (WCF) safe #1 in advance of ceremony 2. At the WCF ceremony 2, 
the TEB were retrieved from the safe at steps 35-38, and the TEB tamper 
clues were verified at steps 73-76.

For the record, this key material exited the WCF HSM 
technology-intensive world at ceremony 1 step 60 and re-entered the ECF 
HSM #1 at ceremony 2 step 77-78. (The key material also entered WCF HSM 
#2 and ECF HSM #2.)

I don't have a question. I will trust the DNSSEC root signatures. 
However, it seems obvious that formal dual-control rules should have 
been designed, e.g. a "Trusted Courier Officer" role with a 3 out of 4 
(or 5) separation of duty. Without this, the key material has been 
protected only by the tamper-evident protection in transit from the ECF 
to the WCF. This role would have been limited in time.

I don't want to discuss the effectiveness of tamper-evident envelopes, 
or the additional controls built around the core key material in the HSM 
technology. These are mainly obfuscating the core principles.

> 
>> Is there an emergency KSK rollover strategy?
> 
> Yes, please read the DPS - https://www.iana.org/dnssec/icann-dps.txt.
> 
> 
> 	jakob (member of the Root DNSSEC Design Team)
> 
> --
> Jakob Schlyter
> Kirei AB - http://www.kirei.se/
> 
> 

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