On Tue, 26 Aug 2008, Ted Lemon wrote:
> On Aug 26, 2008, at 1:06 PM, Dean Anderson wrote:
> > How could their testing and analysis be considered 'thorough' or
> > credible when they didn't find the very serious flaws just recently
> > identified on this list?
>
> To summarize, the two "flaws" to which you refer are:
I'm not sure I agree with your summary of the NSEC/NSEC3 issues. I'll
mostly ignore your summary for now and just note that there are a number
of other serious flaws.
3. Ordinary cache poisoning still possible in DNSSEC-aware non-verifying
caches, resulting in a DOS.
4. Crypto-overload DOS attack on verifying caches.
5. New, hard to mitigate, DDOS attack using forged DNSSEC queries to
roots, TLDs, large domains with an amplification factor near 100:1.
I'm still looking into the private key recovery issue. I'll try to
finish that up tonight.
Some comments on incorrect assertions on the NSEC/NSEC3 attacks.
> (1) there is no cryptographic defense against an attack where the
> attacker convinces the target that a zone that does not exist at all
> does exist.
> (2) replay attacks are possible during the lifetimes of zone
> signatures, which would either convince the target that a zone that
> has been removed still exists, or that a zone that has been added does
> not exist.
> (1) [...] what this
> limitation means is that your delegations are not signed for free - if
> you want any security at all out of DNSSEC, you must sign your zone.
One cannot sign zones that don't exist. The NSEC/NSEC3 exploit allows
one to create zones that don't exist. The end-user can't determine that
they don't really exist.
> I don't see any way around (2), but would be interested in hearing any
> proposals you have. Replay attacks are a problem in protocols with
> long-lived signatures, and this is one variable to take into account
> when choosing a zone signature lifetime.
The first thing is to quit telling people that DNSSEC is secure. It
isn't. One merely does different things (set the DO bit, craft a
response with DNSSEC RRs, etc) to obtain the same objectives as before.
I also propose to obsolete RFC4033, 4034, 4035 and remove the type codes
for DNSKEY, DS, RRSIG, NSEC RR types.
> Also, of course, if I have mischaracterized the limitations to which
> you refer, I would be interested in being corrected - are there any
> additional lies that can be told using the second flaw, for example?
The sky is the limit. Since the zone appears not to exist by (2), it
can be made to exist using (1). That's also cache poisoning by any
other name.
--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
