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 majord...@metzdowd.com
