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

[Mukund Sivaraman <[e-mail]>]

Hi Jinmei

On Wed, Jul 19, 2017 at 04:14:11PM -0700, 神明達哉 wrote:
> At Tue, 18 Jul 2017 18:20:56 +0530,
> Mukund Sivaraman <[e-mail]> wrote:
> 
> > 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.
> 
> 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).

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