Hi Nicholas On Wed, Jan 04, 2017 at 09:33:04AM -0800, Nicholas Weaver wrote: > This way, you can deploy this solution today using white lies, and as > resolvers are updated, this reduces the potential negative consequence > of a key compromise to “attacker can only fake an NXDOMAIN”, allowing > everything else to still use offline signatures. > > Combine with caching of the white lies to resist DOS attacks and you > have a workable solution that prevents zone enumeration that is > deployable today and has improved security (key can only fake > NXDOMAIN) tomorrow.
Assume an attacker is able to spoof answers, which is where DNSSEC
validation helps. If a ZSK is leaked, it becomes a problem only when an
attacker is able to spoof answers (i.e., perform the attack).
What you're saying is that with a special NSEC3-only DNSKEY compromise,
"attacker can only fake an NXDOMAIN". If an attacker can fake NXDOMAINs
and get the resolver to accept them, that's as bad. The attacker can
deny all answers in the zone by presenting valid negative answers. This
is why we have proof of non-existence that needs to be securely
validated. A special NSEC3-only-DNSKEY's compromise isn't a better
situation than a ZSK compromise.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
