Subject: Re: nsec3 and opt-in

From: Paul Vixie <[email-masked]>
Date: Mon, 08 Aug 2005 14:12:28 +0000

roy wrote:

# > Even though anti-enumeration and opt-in techniques offer solutions for
# > different problems (in fact, I see them as orthogonal) they have
# > authenticated denial in common, and authenticated denial is based on a
# > single resource record type.
# >
# > I argue that it is far more complex to separate these solutions into
# > different signaling schemes using different resource records or
# > meta-types. I view it as logical to signal opt-in using NSEC3 instead of
# > signaling opt-in by some other means.

alex added:

# All of the above I agree with.

the previous decision-tree on opt-in would lead to this option being hardwired
to "off".  after all, if opt-in were to be allowed in NSEC, such that the only
names subject to zone walking were those not at delegation points or
delegations to secure subzones, then there would be insufficient market
pressure for NSEC3.

so, to be consistent with this working group's position on opt-in in NSEC, it
should not be present in NSEC3, or conversely, if this working group is willing
to enable opt-in in NSEC3, then we should take the much shorter path by just
enabling it in NSEC.

alex continues:

# The "do we do these at the same time" question should thus depend
# on the following two thing:
# 1. Does incorporation of opt-in make the standards process and deployment
#    of NSEC3 significantly harder? (for instance, because it at least
#    arguably introduces a new state - non-authenticated denial within
#    a signed zone - for the next layer up)

i don't think it matters.  verisign is planning to sign .COM with
NSEC3+opt-in, assuming that opt-in survives in the NSEC3 design.  that
makes any pre-NSEC3 deployment "non-sticky" and therefore irrelevant --
since .COM is "where most the names are", there is no point in planning
for a lasting population of NSEC-only validators, and NSEC3/opt-in will
constitute a flag day on par with "DNSSEC-ter".

due to this "additional flag day" effect, there's no reason to worry
about the time or difficulty-level of getting NSEC3 completed.

# 2. If the answer to Q1 is yes, does this matter (for instance, taking
#    an extreme example, if there were 100 other showstopper issues with
#    DNSSEC-bis that suddenly arose and required a lot of protocol
#    reengineering to fix, (1) becomes irrelevant).

the reason (1) is irrelevant is explained above.

# Those arguing against opt-in were arguing the answer to (1) was either
# "yes" or at best "it will taking some serious thinking an argument to
# come to an answer".

those arguing against opt-in were protocol moralists, i.e., that DNSSEC
should not be as autonomous as DNS ("other zone owners should not have this
feature available, it's not enough that i myself won't use this option.")

if we're ready to discard that reasoning, let's re-admit mark kosters' NSEC
opt-in proposal, and find out if there's anybody left who still cares about
NSEC3.

if we're not ready to discard that reasoning, then opt-in has to be left out
of NSEC3.

paul

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Roy Arends <[email-masked]>
Date: Mon, 8 Aug 2005 17:35:16 +0200 (CEST)

Paul,

> to "off".

I'm not sure the previous decision-tree on opt-in still holds, since at
least parts of that tree was based on introducing (more) delay
in publishing the -bis drafts. We are past that point.

> after all, if opt-in were to be allowed in NSEC, such that the only

The two solutions address different problems brought on by different
partoes. I think its rather short to assume that NSEC3 'market pressure'
gets insufficient if opt-in were to be allowed in NSEC.

Opt-in addresses zone size, hashed-ownernames address anti-enumeration. I
agree that opt-in slightly helps against enumeration (of unsigned
delegations), but does not do this as efficiently as hashed ownernames.

> so, to be consistent with this working group's position on opt-in in
> NSEC, it should not be present in NSEC3, or conversely, if this working
> group is willing to enable opt-in in NSEC3, then we should take the much
> shorter path by just enabling it in NSEC.

I think this argument does not hold, given it is based on an assumption
that is hard to measure, and a decision tree that is at least partly
invalidated.

> opt-in proposal, and find out if there's anybody left who still cares about

This is very hard to do, since the -bis drafts are already published. I
would not recommend updating the -bis drafts.

> if we're not ready to discard that reasoning, then opt-in has to be left out

There is ofcourse the third option: if we're ready to discard that
reasoning, let's have the opt-in proposal with anti-enumeration:The one
currently on the table, draft-ietf-dnsext-nsec3.

Roy