AW: [governance] US Congrerss & JPA

[Joe Baptista]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.igcaucus.org/pipermail/governance/attachments/20090810/7d372c6b/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