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

From: Nicholas Weaver <[email-masked]>
Date: Wed, 4 Jan 2017 09:33:04 -0800

Any system which prevents zone enumeration requires online signing, https://www.cs.bu.edu/~goldbe/papers/nsec5faq.html

But NSEC5 is almost certainly not going to be adopted, simply because of the partial deployment problem.

NSEC3 lies work today, but people worry that NSEC3 might have server compromise compromise the ZSK.

So why not simply add a new DNSKEY record flag: NSEC3-only.  This flag means that the key in question can only be used to sign an NSEC* record when presenting NXDOMAIN.

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.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 4 Jan 2017 23:54:16 +0530

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

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 4 Jan 2017 10:28:11 -0800

> On Jan 4, 2017, at 10:24 AM, Mukund Sivaraman <[email-masked]> wrote:
> 
> Hi Nicholas
> 

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.

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 5 Jan 2017 00:05:52 +0530

Hi Nicholas

On Wed, Jan 04, 2017 at 10:28:11AM -0800, Nicholas Weaver wrote:
> 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

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 5 Jan 2017 00:15:52 +0530

> compromised the key or not.

A SERVFAIL is an erroneous condtion. An NXDOMAIN is not - it is business
as usual. SERVFAILs are sometimes cached very temporarily to reduce load
on upstream servers, but they are not answers. NXDOMAINs are cached as
*answers* from the remote auth server.

On-path disruption is impossible to defeat. An on-path attacker who
wants to poison answers without raising suspicions (logged validation
failures) will want validation to succeed.

		Mukund

---

From: Matthäus Wander <[email-masked]>
Date: Thu, 5 Jan 2017 14:13:12 +0100

> situation than a ZSK compromise.

You're right if you're only considering denial of service.
If you take phishing or email hijacking into account, an NSEC3-only
compromise is a better situation than a ZSK compromise (or at least a
different attack class, whether or not better).

With DANE, however, it's not just denial of service anymore: NXDOMAIN
spoofing cancels the protection provided by DANE.

So we have the cost of a protocol change vs. the benefit of protecting
from bogus records (but not from DoS or DANE downgrade)...

Regards,
Matt

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 05 Jan 2017 09:05:52 -0800

On 4 Jan 2017, at 9:33, Nicholas Weaver wrote:

> Any system which prevents zone enumeration requires online signing, 
> https://www.cs.bu.edu/~goldbe/papers/nsec5faq.html

That statement isn't really supported by the text on the page. Depending 
on the zone, using pre-signed NSEC3 prevents varying amounts of 
enumeration, depending on what's in the attacker's dictionary and what's 
in the zone.

> of the partial deployment problem.

Yes.

> compromise compromise the ZSK.

NSEC3 lies can also be created with pre-computing, but at a cost of 
greatly increasing the size of the zone.

> So why not simply add a new DNSKEY record flag: NSEC3-only.  This flag 
> means that the key in question can only be used to sign an NSEC* 
> record when presenting NXDOMAIN.

This could be done if there are enough people who care about zone 
enumeration against the current NSEC3 capabilities. Are there such 
people? Have we heard what their problem statements are and what they 
have tried with pre-computed NSEC3 lies?

--Paul Hoffman

---

From: Matthäus Wander <[email-masked]>
Date: Thu, 5 Jan 2017 20:27:19 +0100

> greatly increasing the size of the zone.

NSEC/NSEC3 lies prevent enumeration effectively when they're minimally
covering because it's infeasible to ever collect such a chain.

A pre-computed chain does not provide the same benefit. It increases the
enumeration cost in terms of network queries (CPU time is of less
importance here because the collection process is network-bound except
for the very last few NSEC3 records). Enumeration remains feasible with
pre-computed chains unless you re-salt and re-sign the zone in an
interval, which is shorter than the duration needed to send one query
for each NSEC3 record in a zone.

Regards,
Matt

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 05 Jan 2017 11:44:01 -0800

> covering because it's infeasible to ever collect such a chain.

Sure.

> for each NSEC3 record in a zone.

Doesn't that last sentence assume that the attacker has a complete 
dictionary of possible values in the zone?

--Paul Hoffman

---

From: Matthäus Wander <[email-masked]>
Date: Thu, 5 Jan 2017 21:41:06 +0100

> dictionary of possible values in the zone?

To collect an NSEC3 record it suffices to find a random non-existing
name, whose hash value cuts the NSEC3 record. This does not require a
lot of hashing attempts and a dictionary is not required. By keeping
track of which NSEC3 records you have already seen, you only need to
send network queries for hash ranges not yet discovered.

This gives you the whole NSEC3 chain, though not the cleartext names
yet. The cost for recovering cleartext names depends on the iteration
count and the number of candidate names you try (i.e. size of
dictionary), but not (or maybe little) on the size of the chain.

Regards,
Matt

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 5 Jan 2017 18:53:00 -0500

On Wed, Jan 4, 2017 at 12:33 PM, Nicholas Weaver <[email-masked]>
wrote:

> means that the key in question can only be used to sign an NSEC* record
> when presenting NXDOMAIN.
>

I used to think that was a good idea, but .... given that this will add
keys to the DNSKEY set I think it is not worth it with RSA the DNSKEY sets
are too large in most cases.
With ECC keys on the other hand this might be reasonable.

What is the problem you are solving by having a NSEC-only key ?
is it key management,  sharing keys with DNS operators, or something else.

At Cloudflare we sign a all DNSEC answers on the fly with the exception of
DNSKEY/CDS/CDNSKEY which we have to do centrally.
This is working and we do not worry too much about ZSK compromise, as we
can roll them when we need.
 We just use Minimally covering NSEC records (no need to do NSEC3),
we are looking into adoption that on the fly when under random prefix DDoS
attacks, to resolvers that we know support agressive NSEC processing.

> 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.
>
>
Why is key compromise in DNS more worrying than in HTTPS ?
HTTP servers have keys online all the time.

> 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.
>
>
The problem with a FLAG is that it will require
a) validator/resolver support
b) have a workable key management

I think we can do this w/o the flag

Regards,
Olafur