On Fri, 22 Aug 2008, Ted Lemon wrote:
> On Aug 22, 2008, at 7:23 AM, Dean Anderson wrote:
> > Sigh. Above is precisely the sort of non-critical analysis that causes
> > these things to have so many problems.
>
> Instead of making fun of other peoples' lack of critical thinking, you
> might want to take responsibility for your own thinking and let others
> take responsibility for theirs.
I didn't make fun of anyone. The lack of critical analysis is no
laughing matter.
None of the promoters seems to ever make an effort to consider how
things might break. There is far too much cheerleading and far too
little of how it could break.
> The problem with your reasoning is that the resolver is configured
> with a trust anchor, and the zone with the missing DS records is below
> that trust anchor.
There is no problem with my reasoning. Let me spell it out in more
detail:
The NSEC/NSEC3 issue has already been explained, but you didn't get the
implications. The NSEC/NSEC3 opt-out records just signal that an
unsigned zone exists (or could exist)
>From RFC5155:
The presence of Opt-Out in a zone means that some additions or
delegations of names will not require changes to the NSEC3 RRs in a
zone.
o When removing a delegation RRSet, if that delegation does not have
a matching NSEC3 RR, then it was opted out. In this case, nothing
further needs to be done.
o When adding a delegation RRSet, if the "next closer" name of the
delegation is covered by an existing Opt-Out NSEC3 RR, then the
delegation MAY be added without modifying the NSEC3 RRs in the
zone.
And the delegation records are unsigned; the resolver has no way to know
if they are correct; The delegation was picked so that NSEC3 RR's
didn't change with the addition, and so the NSEC3 RRs verify correctly.
The bad guy just uses those NSEC3 records 'as-is'.
So one can use poison on a validating DNSSEC resolver to achieve false
resolution for any "new" unsigned zone. Put another way, the bad guy
can create new delegations under opt-out NSEC3 records.
One can also do this exact same thing on signed delegations provided you
have an earlier copy of a covering NSEC3 record signed with the same
key. [So operators have to rekey anytime they create a new delegation.]
In fact, it seems that rekeying has to be done on any change, else the
old NSEC records can be used to poison caches.
-- The assertion that validating DNSSEC caches can't be poisoned is
false.
-- This attack works on non-validating caches as well.
-- Also, non-validating DNSSEC-aware caches are trivially poisonable to
obtain a DOS attack.
-- Key rollover is a much more frequent issue than has been described by
promotors of DNSSEC.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
