Subject: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 18 Jul 2017 15:16:54 +0530

Hi all

There are still many popular unsigned zones, many of which don't look
like they will be signed soon due to operational and other reasons.

Will you give some thought and reply with your opinion on NSEC/NSEC3 for
unsigned zones requiring the DNS COOKIE option in transmission, that can
be used with draft-ietf-dnsop-nsec-aggressiveuse?

		Mukund

---

From: Francis Dupont <[email-masked]>
Date: Tue, 18 Jul 2017 13:17:58 +0200

>  be used with draft-ietf-dnsop-nsec-aggressiveuse?

=> I can't parse your message:
 - unsigned zones have no zone keys
 - DNS cookie was designed to give a return routability proof for the client,
  not the server
 - there is no NSEC/NSEC3 in an unsigned zone
Perhaps you mean to return a synthesized NSEC/NSEC3 and the DNS COOKIE is
as usual required to avoid amplification DoS.
But what will be the signing key (including on the client side) and
what to put in the NSEC/NSEC3? Perhaps this applies only to authoritative
servers of the (unsigned) zone?
It seems easier to remember that DNSSEC offers proofs for denial of existence.

Regards

[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 18 Jul 2017 12:41:38 +0100

> It seems easier to remember that DNSSEC offers proofs for denial of existence.

Yes. Surely we don't want to make the DNS even more complicated just to
undemine one of the positive features of DNSSEC.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Southeast Iceland: Southeasterly 5 to 7, occasionally gale 8 in west. Moderate
becoming rough, occasionally very rough for a time in west. Rain later. Good,
occasionally poor later.

---

From: Jim Reid <[email-masked]>
Date: Tue, 18 Jul 2017 12:44:46 +0100

> On 18 Jul 2017, at 12:17, Francis Dupont <[email-masked]> wrote:
> 

Except when it doesn't. :-) RFC5155 includes opt-in.

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 18 Jul 2017 17:27:39 +0530

Hi Francis

>  - unsigned zones have no zone keys

NSEC needs no keys, only their RRSIGs would which wouldn't exist in
unsigned zones. In this case the unsigned NSEC would also not be part of
the zone (it would have to be synthesized and maintained outside the
zone).

> as usual required to avoid amplification DoS.

This was discussed during the ISC 2017 all-hands; I don't remember if
you were in the meeting when we discussed it (I think the meeting topic
was about DoS mitigation measures).

Because an unsigned/unauthenticated NSEC/NSEC3 has the potential to nix
entire zones, when it was discussed, Mark Andrews suggested that
requiring DNS COOKIE to further reduce the chance of cache poisoning
(more than source port randomization and random message ID) could be a
reasonable idea to think about.

		Mukund

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 18 Jul 2017 14:35:31 +0200

> be used with draft-ietf-dnsop-nsec-aggressiveuse?

Of what value is the result? Is it worth the hassle for the zone admin?

--Paul Hoffman

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 18 Jul 2017 18:20:56 +0530

Hi Paul

> Of what value is the result? Is it worth the hassle for the zone admin?

It is to put draft-ietf-dnsop-nsec-aggressiveuse to use with unsigned
zones. A zone admin would not have to do anything operationally except
enable/disable the feature.

Dealing with water torture and some other attacks have had several
band-aid approaches that don't always work well in practice. The most
promising (and what feels correct) is
draft-ietf-dnsop-nsec-aggressiveuse, but it doesn't work for unsigned
zones.

		Mukund

---

From: Petr Špaček <[email-masked]>
Date: Tue, 18 Jul 2017 15:14:04 +0200

> draft-ietf-dnsop-nsec-aggressiveuse, but it doesn't work for unsigned

For me this is an incentive to get more zones signed, not to add kludges
just for unsigned ones.

There surely are "operational and other reasons" not to sign zone
associated with some cost. Signing and serving signed zone have cost_1
and serving unsigned zone has cost_2 (which needs to incorporate cost of
attacks mitigated by DNSSEC).

Eventually cost_2 of serving unsigned zone might get high enough so
solving "operational and other reasons" might be cheaper than cost_1
paying for signing and serving signed zone. I would wait for that.

-- 
Petr Špaček  @  CZ.NIC

---

From: Francis Dupont <[email-masked]>
Date: Wed, 19 Jul 2017 10:50:47 +0200

>  the zone (it would have to be synthesized and maintained outside the

=> but it is created by an authoritative server, isn't it?
And as it is synthesized I can't see a good reason to use NSEC3 instead.

>  reasonable idea to think about.

=> it adds a nonce so another (short) bunch of unpredictable bits.
As NSEC is not signed it is more than vulnerable to on-the-path attacks.
I am afraid it is first a massive zone destruction weapon and after
perhaps an optimization...

>  > It seems easier to remember that DNSSEC offers proofs for denial of

=> still applies...

Regards

PS: really if this is deployed I can see more "interesting" ways for misuses
than real benefits. Of course it can be a mean to make zone managers
to rush on DNSSEC...

---

From: 神明達哉 <[email-masked]>
Date: Wed, 19 Jul 2017 16:14:11 -0700

At Tue, 18 Jul 2017 18:20:56 +0530,

> draft-ietf-dnsop-nsec-aggressiveuse, but it doesn't work for unsigned

Do you mean it's the most promising measure for authoritative servers?
If so, and if nsec-aggressiveuse is more widely deployed in resolvers,
and if the authoritative operators feel the pain so keenly, I'd rather
imagine they are willing to pay the cost of deploying DNSSEC.

If you mean it's the most promising measure for recursive servers, I
simply don't buy the argument.  (I made that comment while the wg
discussed nsec-aggressiveuse and it toned down quite a lot in that
sense as a result of it, so I believe it's based on a wg rough
consensus).

So, either way, I don't see a strong case for the trick of using
nsec-aggressiveuse on an unsigned zone with DNS cookies.

--
JINMEI, Tatuya

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 20 Jul 2017 14:37:23 +0530

Hi Jinmei

> sense as a result of it, so I believe it's based on a wg rough

I had meant only one of the benefits that nsec-aggressiveuse brings:

* Avoid creating unnecessary fetches from the resolver by being able to
  answer more queries from cache

(... ignoring the wildcard case.)

It would help an auth service indirectly (if resolvers don't send it as
many queries) but it has to handle the queries it gets.

There are different approaches that are being used for handling water
torture style attacks (bloom filtering with previously seen queries,
fetches-per- controls, BLOOM RR type, etc.)  but compared to those
methods, NSEC aggressive use is a "correct" absolute method to stop
fetches to non-existent names and data that works with minimal
implementation changes only.

A lot of popular zones are still unsigned. There are different reasons
for it. Without advocating against DNSSEC, I want to point out that the
all-or-nothing behavior of validation needs absolute correctness
end-to-end in all pieces that some zone owners think about when
considering whether to sign their zones.

There are still implementation bugs. E.g., recently for several
weeks/months, .ORG had a problem where it would not allow a DS record to
be marked as removed. This meant that a child zone that wanted to go
from signed to unsigned state could not do so (my own zones were
affected).

A zone signer implementation bug (e.g., untimely RRSIG generation
causing no new RRSIGs to be added before existing RRSIGs expire) has the
capability to take down all internet services at a domain. This still
happens today, believe it or not. A zone owner has no control over
schemes like using negative trust anchors at each resolver. There is the
potential of significant economic loss to a business due to downtime
that owners think about.

Such frailty in the DNSSEC state of implementation has to improve before
advocating DNSSEC as a solution to all problems. The fact that NSEC is a
DNSSEC feature, and that it solves handling negative answer queries is a
side-effect, but considering things individually, solving water torture
style attacks doesn't need the rest of DNSSEC. It needs NSEC.

(Please don't think that I'm advocating against DNSSEC. These are
problems I come across practically as a programmer for a DNS
implementation.)

We have several popular unsigned zones today. It is the resolver side
that has to answer for random non-existent subdomains under these zones.

When talking about taking away the RRSIG of NSEC, it causes people to
feel uncomfortable, but unsigned zones are unsigned after all. Whatever
modification can be done by an attacker with an unsigned NSEC can be
done right now too for individual queries. There should be more thought
about benefit vs. risk of using such a scheme.

		Mukund

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Jul 2017 17:00:31 +0200

On Tue, Jul 18, 2017 at 06:20:56PM +0530,
 Mukund Sivaraman <[email-masked]> wrote 

> It is to put draft-ietf-dnsop-nsec-aggressiveuse to use with unsigned

That's quite funny. During the development of RFC 8020
(draft-ietf-dnsop-nxdomain-cut), which addresses the same concern as
draft-ietf-dnsop-nsec-aggressiveuse, many people said that the feature
was dangerous, and we should mandate the use of DNSSEC. In the end, it
is not mandatory (see sections 2, 3rd para, and section 7 of RFC
8020).

draft-ietf-dnsop-nsec-aggressiveuse is more aggressive (because it can
now synthetizes answers) so it seems to me the same reasons should
apply?

---

From: Petr Špaček <[email-masked]>
Date: Fri, 21 Jul 2017 10:24:35 +0200

> perhaps an optimization...

Oh yes, very good point Francis. Let me repeat that I'm against this
proposal.

Petr Špaček  @  CZ.NIC

---

From: Petr Špaček <[email-masked]>
Date: Fri, 21 Jul 2017 10:30:13 +0200

> is not mandatory (see sections 2, 3rd para, and section 7 of RFC

It is worth noting that implementation in Unbound enables this only for
DNSSEC-signed zones to avoid problems with broken CDNs.

In other words, DNSSEC is used as indicator "we can do DNS properly".
That sounds reasonable to me.

Petr Špaček  @  CZ.NIC

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 21 Jul 2017 14:53:01 +0530

> Oh yes, very good point Francis. Let me repeat that I'm against this

The zone is unsigned. An on-path attacker can do pretty much whatever he
pleases anyway including poisoning cache and denying service.

The addition of the cookie was to prevent the risk of an off-path attack
becoming a massive zone destruction weapon.

		Mukund

---

From: "Peter van Dijk" <[email-masked]>
Date: Sat, 22 Jul 2017 01:47:21 +0200

> now synthetizes answers) so it seems to me the same reasons should

That it is more aggressive, -and- that it relies on a feature of DNSSEC, 
suggests that we SHOULD be stricter here, and the only interpretation of 
‘stricter’ I can imagine is requiring DNSSEC.

However, I have advocated (offline) in the past for allowing unsigned 
NSEC to be used to deter PRSD attacks, allowing the resolver to reduce 
queries to the targeted auth by >90% - a win for both sides. It is a 
tricky balance. If somebody is under attack, that surely is the worst 
time for them to upload a DS, while enabling DNSSEC on their end (which 
would come with RRSIGs that validators then ignore) as a mitigation 
strategy that actually works, would be wonderful to have.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/