DNSSEC is a bit of a joke and no one should consider it seriously.<br><br>Essentially DNSSEC attempts to address a bug in DNS that has existed since the beginning of DNS deployment. The security issues in DNS have nothing to do with the DNS protocol but are directly related to issues in the UDP transport protocol.<br>
<br>DNSSEC attempts to address these issues by incorporating an addition layer of complexity into the DNS through the deployment of trust anchors along the DNS hierarchy. The actual security issue in the UDP protocol is never addressed in DNSSEC.<br>
<br>That security issue exists because of the nature of the UDP protocol. Without going into the complex details let me say that UDP is easy to spoof. DNSSEC just makes it slightly harder to spoof.<br><br>A solution to the UDP problem has been developed by Bernstein. It's called DNSCurve.<br>
<br><a href="http://bit.ly/pJVq4">http://bit.ly/pJVq4</a><br><br>enjoy<br>joe baptista<br><br>p.s. at one time DNSSEC could jeopardize alternative root operations. That has been fixed but to my knowledge never tested. <br>
<br><div class="gmail_quote">On Sun, Aug 9, 2009 at 10:51 PM, Karl Auerbach <span dir="ltr"><<a href="mailto:karl@cavebear.com">karl@cavebear.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 08/09/2009 03:06 PM, Milton L Mueller wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Do you agree with me and with Philip Hallam-Baker that implementation<br>
of DNSSEC makes it much more difficult, if not impossible for<br>
multiple, consistent roots to be maintained?<br>
</blockquote>
<br></div>
I personally have not dredged into DNSSEC to make my own assessment. (Although in preparing this reply I have lightly dug into the DNSSEC RFCs.)<br>
<br>
A few months ago I asked this question of someone I trust who is deeply involved with DNSSEC. His answer was that DNSSEC would not have the effect of blocking competing roots. (He may have changed his opinion since then, but I have not heard to the contrary.)<br>
<br>
His rationale was to the effect that since DNSSEC is really, just like DNS, a hierarchy of keys, what matters is that there is a downwards looking chain of keys (via signed DS/DNSKEY records) from whatever one accepts as "the root" (or "trust anchor".)<br>
<br>
>From my reading of DNSSEC RFC's a DNSSEC capable competing root would need to provide DS records for all of the TLDs that have a zone key (DNSKEY) record. That, I believe (but I can be wrong) can be done by the competing root, as part of its root zone generation process, going to each of the TLDs that are in its zone and asking for the DNSKEY record and then computing an appropriate DS record for inclusion into the competing root zone.<br>
<br>
It seems to me that given that we today can run DNSSEC child zones under non DNSSEC parent zones, that it would be feasible for some competing roots to be DNSSEC signed (which DS records for delegations) and others not. But again I'm speaking from light reading not from deep knowledge.<br>
<br>
(For a root with a few hundred delegations that, assuming I'm not completely off base, would be fairly easy to do. For a huge TLD such as .com I would imagine that this would require something like a DNS version of a Google-bot to continuously dredge through that TLD's clients [e.g. <a href="http://example.com" target="_blank">example.com</a>] to find new and updated DNSKEY records.)<br>
<br>
Now I could be absolutely and totally wrong in this. But from my (admittedly light) reading of DNSSEC all of the signing such that a child-zone (e.g. <a href="http://example.com" target="_blank">example.com</a> is a child of .com and .com is a child of a root) contains no cryptographic materials to verify the parent. Rather that the parent provides crypto materials of the child. This suggests to me that a child zone could have any number of DNSSEC parents as long as each parent itself has a DS record for the child and that that DS record is signed by the DNSKEY of the parent, a key that can be different for each parent. I.e. multiple parents implies the ability of multiple roots.<br>
<br>
Again I could be dead-to-rights wrong on all of this. But for a couple of years I've been asking to be corrected in specific terms and so far nobody has taken me to task.<br>
<br>
It would be worthwhile to move this out of the abstract and to set up a DNSSEC testbed to test these exact scenarios.<div><div></div><div class="h5"><br>
<br>
--karl--<br>
<br>
<br>
<br>
<br>
<br>
____________________________________________________________<br>
You received this message as a subscriber on the list:<br>
<a href="mailto:governance@lists.cpsr.org" target="_blank">governance@lists.cpsr.org</a><br>
To be removed from the list, send any message to:<br>
<a href="mailto:governance-unsubscribe@lists.cpsr.org" target="_blank">governance-unsubscribe@lists.cpsr.org</a><br>
<br>
For all list information and functions, see:<br>
<a href="http://lists.cpsr.org/lists/info/governance" target="_blank">http://lists.cpsr.org/lists/info/governance</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Joe Baptista<br><br><a href="http://www.publicroot.org">www.publicroot.org</a><br>PublicRoot Consortium<br>----------------------------------------------------------------<br>
The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large.<br>----------------------------------------------------------------<br> Office: +1 (360) 526-6077 (extension 052)<br>
Fax: +1 (509) 479-0084<br><br>Personal: <a href="http://www.joebaptista.wordpress.com">www.joebaptista.wordpress.com</a><br>