> On Jan 4, 2017, at 10:24 AM, Mukund Sivaraman <m...@isc.org> wrote: > > 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.
An attacker in that position can just put in garbage, and you get SERVFAIL instead of NXDOMAIN, regardless of whether the attacker has compromised the key or not. This is partially why the provable denial is somewhat silly as I can have the same effect as a denial of service using other mechanisms that the cryptography doesn’t stop. So having a key that can only be used for provable denial compromised by an attacker is, yeah, not great, but not some horrid catastrophe. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
