Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only...

[Mukund Sivaraman <[e-mail]>]

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 <[e-mail]> 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