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

        jakob (member of the Root DNSSEC Design Team)

Jakob Schlyter
Kirei AB -


- 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

Reply via email to