On Aug 22, 2008, at 6:27 PM, Dean Anderson wrote:
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.
If you had actually followed any of the discussions about DNSSEC over
that last 13 years, you would know that this is false. Thinking about
how it could break is what the vast majority of work on this topic has
been about.
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)
Unsigned delegations, not zones.
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'.
In all forms of DNSSEC (NSEC3 or NSEC) the delegation records are
unsigned. This is not a problem because, if the delegation is secure
(i.e., has a DS RRset), the referred-to zone MUST have a DNSKEY that
matches one of the DS records. If not, then the response is
considered bogus and (normally) thrown away.
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.
This fact is specifically mentioned in the Security Considerations
section of RFC 5155, so, true.
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.]
No, you don't. This old NSEC3 (or NSEC) RRset isn't valid forever.
In fact, it seems that rekeying has to be done on any change, else the
old NSEC records can be used to poison caches.
No, this is why RRSIG records have expiration times.
It is well understood that you are vulnerable to a replay attack while
the old RRSIGs are still valid. Which argues for short signature
durations, not rekeying.
--
David Blacka <[EMAIL PROTECTED]>
Sr. Engineer Platform Product Development
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
