Re: Root Zone DNSSEC Deployment Technical Status Update
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. 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. 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. 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/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Root Zone DNSSEC Deployment Technical Status Update
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
Re: Fw: Root Zone DNSSEC Deployment Technical Status Update
On Fri, 16 Jul 2010, Taral wrote: Neat, but not (yet) useful... only these TLDs have DS records: The rest will follow soon. And it is not that you had to stop those TLD trust anchors just now. Several are using old SHA-1 hashes... old ? Paul - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Root Zone DNSSEC Deployment Technical Status Update
At 9:52 AM -0400 7/17/10, Thierry Moreau wrote: 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. Thierry, can you say how using one of those alternatives would look different than the DURZ that they used? Should they all be marked as unverfied in a compliant DNSSEC resolver? If not, I am interested in how you think the differences would have manifest in the real world. 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. FWIW, this was *widely* publicized, particularly on mailing lists that Thierry is on. It even made the IT trade press. As a side note, I find the IT press part disturbing, given that the key signing ceremonies were just as much security theater as many of the things we like to chide on this list. 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. insert chide about your criticism of the exact shade of red used on the curtains in the theater --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Root Zone DNSSEC Deployment Technical Status Update
Paul Hoffman wrote: At 9:52 AM -0400 7/17/10, Thierry Moreau wrote: 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. Thierry, can you say how using one of those alternatives would look different than the DURZ that they used? Should they all be marked as unverfied in a compliant DNSSEC resolver? Yes. E.g. if a zone is signed only by algorithm GOOSE_128, and your validating resolver does not know this algorithm, the DNS zone data remains insecure (this is what you mean by unverified I guess). That's in the DNSSEC protocol. 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
Re: Fw: Root Zone DNSSEC Deployment Technical Status Update
On Sat, Jul 17, 2010 at 7:41 AM, Paul Wouters p...@xelerance.com wrote: Several are using old SHA-1 hashes... old ? old in that they are explicitly not recommended by the latest specs I was looking at. -- Taral tar...@gmail.com Please let me know if there's any further trouble I can give you. -- Unknown - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
