Re: Fw: Root Zone DNSSEC Deployment Technical Status Update
On Sat, Jul 17, 2010 at 10:41:10AM -0400, Paul Wouters wrote: 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. actually, soon is a relative term. Some have stated they are waiting for operational issues to settle before they proceed. could be a few months, could be a few years. Several are using old SHA-1 hashes... old ? :) really old. Paul - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Root Zone DNSSEC Deployment Technical Status Update
On Jul 17, 2010, at 3:30 05PM, Taral wrote: 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. DNSSEC signatures do not need to have a long lifetime; no one cares if, in 10 years, someone can find a preimage attack against today's signed zones. This is unlike many other uses of digital signatures, where you may have to present evidence in court about what some did or did not sign. It's also unclear to me what the actual deployment is of stronger algorithms, or of code that will do the right thing if multiple signatures are present. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
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
Fw: Root Zone DNSSEC Deployment Technical Status Update
The root zone has been signed, and the root zone trust anchor has been published. Begin forwarded message: Date: Fri, 16 Jul 2010 14:35:39 + From: Joe Abley joe.ab...@icann.org To: na...@nanog.org Subject: Root Zone DNSSEC Deployment Technical Status Update Root Zone DNSSEC Deployment Technical Status Update 2010-07-16 This is the twelfth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. RESOURCES Details of the project, including documentation published to date, can be found at http://www.root-dnssec.org/. We'd like to hear from you. If you have feedback for us, please send it to roots...@icann.org. FULL PRODUCTION SIGNED ROOT ZONE The transition from Deliberately-Unvalidatable Root Zone (DURZ) to production signed root zone took place on 2010-07-15 at 2050 UTC. The first full production signed root zone had SOA serial 2010071501. There have been no reported harmful effects. The root zone trust anchor can be found at https://data.iana.org/root-anchors/. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ 2010-05-05: J starts to serve DURZ 2010-06-16: First Key Signing Key (KSK) Ceremony 2010-07-12: Second Key Signing Key (KSK) Ceremony 2010-07-15: Distribution of validatable, production, signed root zone; publication of root zone trust anchor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Fw: Root Zone DNSSEC Deployment Technical Status Update
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 majord...@metzdowd.com
Re: Fw: Root Zone DNSSEC Deployment Technical Status Update
On Fri, Jul 16, 2010 at 7:47 AM, Perry E. Metzger pe...@piermont.com wrote: The root zone has been signed, and the root zone trust anchor has been published. Neat, but not (yet) useful... only these TLDs have DS records: bg. 172800 IN DS 46846 5 1 1D83F503CCED4A4B6F7F8DB1CF43D38F9133A3EA bg. 172800 IN DS 46846 5 2 26811E459C850F50A85D1EAF589E30DC14D09D1A6E6262E8D36B6BFF C605334C br. 172800 IN DS 41674 5 1 EAA0978F38879DB70A53F9FF1ACF21D046A98B5C cat.172800 IN DS 33436 10 2 E1A0FC89B87F5E7F6B354D364CF704855A2E9A52B7F39BBE4E2BEA44 3B81B18E cz. 172800 IN DS 7978 5 1 9B6C3898470914CDDA98D0CC001688CB32C17A09 cz. 172800 IN DS 9988 5 1 AA94DEC91A18ECAFB85797AEA1031703FC9A6E73 na. 172800 IN DS 24484 5 1 EFC19D4685751FF8E11F96142A083DCB9C708912 tm. 172800 IN DS 28935 7 1 C9660594EFA1DA1B6B7359262F2E11052403 tm. 172800 IN DS 28935 7 2 0C30AA64DF5149B0237F0CAD8E6AB22825BDC8CADBD7CC108F6FFC74 AC428709 uk. 172800 IN DS 15191 8 2 A057C8553B1DC6CF158A87CD2D0BAA2CDC9C6A14FA03DE02B19AB0DA 62AF279E Several are using old SHA-1 hashes... -- 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
