Hi Nicholas On Wed, Jan 04, 2017 at 10:28:11AM -0800, Nicholas Weaver wrote: > > > 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.
An on-path attacker capable of filtering packets is a different
scenario. In this case, nothing can help, not even a secure DNSKEY. When
there's no connectivity, there's no communication.
Off-path attacks are now rarer with source-port randomization and the
introduction of cookies (but we regularly see evidence of attempts to
poison caches).
DNSSEC allows end-to-end validation, where responses do get through and
could be fudged on the way.
> 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.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
