Re: Fw: Root Zone DNSSEC Deployment Technical Status Update

2010-07-18 Thread bmanning
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: Fw: Root Zone DNSSEC Deployment Technical Status Update

2010-07-17 Thread Paul Wouters

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: Fw: Root Zone DNSSEC Deployment Technical Status Update

2010-07-17 Thread Taral
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

2010-07-16 Thread Perry E. Metzger
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

2010-07-16 Thread Thierry Moreau

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

2010-07-16 Thread Taral
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