On Wed, Jun 10, 2009 at 09:18:22AM +0900, Masataka Ohta wrote:
With DNSSEC, a security aware resolver will want to check the signature.
Except for glue A.
That's not a vector for attack. Glue records from the parent side of
the cut are not authoritative data in the parent zone, because the
zone in question has been delegated away. They're only to be used to
stick the two sides of the cut together. (Indeed, treating the
parent-source glue data as authoritative and reusing it as answer data
is in fact a source of poison attacks, as you have quite cogently
pointed out more than once.) If you are validating data, why would
you not follow the chain to the glue record (secured on each side of
_that_ cut by the DS/DNSKEY pairs) and validate the signature on the
authoritative data you get? You'll get a signature over the A record
from the child server, and that signature will either pass or fail
validation according to the same rules as before. (Glue records on
the child side do, of course, come with RRSIGs which can be validated
just like anything else.)
I think people have already heard enough from me on this topic, so I
won't post on it any more. But if you have a real attack that
actually works against DNSSEC in the cases you keep insisting it does,
please show it. Otherwise, please stop insisting DNSSEC is broken.
You haven't shown that it is, and you seem to be making no effort to
provide such a demonstration. There's no question that DNSSEC is
complicated, and that it provides a whole new pile of ways for zone
administrators to screw things up: new features provide a new
opportunity for mistakes. But that's nowise a proof that DNSSEC
itself does not do what it says it does.
Best regards,
Andrew
--
Andrew Sullivan
ajs(_at_)shinkuro(_dot_)com
Shinkuro, Inc.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf