AW: [governance] US Congrerss & JPA

Mon Aug 10 10:30:58 EDT 2009

Come on you guys!  Look at these two consecutive posts.  You two are both of an engineering ilk and yet you use totally non-standard language and even different adjectives, nouns and adverbs -- not to mention names, to speak of exactly the same thing.

If engineers cannot even agree on the same language to use to describe a process, how could we possibly draft any comprehensive or even partial guidelines to governance.

--- On Mon, 8/10/09, Joe Baptista <baptista at publicroot.org> wrote:

From: Joe Baptista <baptista at publicroot.org>
Subject: Re: AW: [governance] US Congrerss & JPA
To: governance at lists.cpsr.org, "Karl Auerbach" <karl at cavebear.com>
Cc: "Milton L Mueller" <mueller at syr.edu>, "Kleinwächter, Wolfgang" <wolfgang.kleinwaechter at medienkomm.uni-halle.de>
Date: Monday, August 10, 2009, 12:55 PM

DNSSEC is a bit of a joke and no one should consider it seriously.

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.

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.

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.

A solution to the UDP problem has been developed by Bernstein. It's called DNSCurve.

http://bit.ly/pJVq4

enjoy
joe baptista

p.s. at one time DNSSEC could jeopardize alternative root operations. That has been fixed but to my knowledge never tested. 

On Sun, Aug 9, 2009 at 10:51 PM, Karl Auerbach <karl at cavebear.com> wrote:

On 08/09/2009 03:06 PM, Milton L Mueller wrote:

Do you agree with me and with Philip Hallam-Baker that implementation
of DNSSEC makes it much more difficult, if not impossible for
multiple, consistent roots to be maintained?

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.)

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.)

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".)

>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.

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.

(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. example.com] to find new and updated DNSKEY records.)

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. example.com 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.

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.

It would be worthwhile to move this out of the abstract and to set up a DNSSEC testbed to test these exact scenarios.

               --karl--

____________________________________________________________
You received this message as a subscriber on the list:
   governance at lists.cpsr.org
To be removed from the list, send any message to:
   governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
   http://lists.cpsr.org/lists/info/governance

-- 
Joe Baptista

www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084

Personal: www.joebaptista.wordpress.com

-----Inline Attachment Follows-----

____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.igcaucus.org/pipermail/governance/attachments/20090810/f57f36e0/attachment.htm>
-------------- next part --------------
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance