Subject: Another NEW technical argument for Opt-In.

From: Roy Arends <[email-masked]>
Date: Wed, 27 Feb 2002 11:39:44 +0100 (CET)

> if someone has NEW technical arguments to present for or against either
> proposal, please do so now.  N_E_W arguments.
>
> randy

With Opt-In, wildcards can be unsigned in a secured zone, and the WG can
optionally ease the current requirements due to wildcards by means of a
new proposal.

The current requirements and complexity due to wildcards are:

(1) If the response is to be a NXDOMAIN response, the current requirement
    is to include authenticated denial (NXT) of wildcards for every
    intermediate label level.
(2) If the response is to be an expanded wildcard, the current requirement
    is to include authenticated denial for a "closer wildcard match" and
    authenticated denial of QNAME.

An example:

Suppose we have

e.       SOA
e.       A
d.e.     A
c.d.e.   A
b.c.d.e. A

A negative response for QNAME "a.b.c.d.e." MUST include:

  b.c.d.e. NXT e.       ([a|*].b.c.d.e. does not exist)
  b.c.d.e. SIG NXT
  e.       NXT d.e.     (*.e. does not exist)
  e.       SIG NXT
  d.e.     NXT c.d.e.   (*.d.e. does not exist)
  d.e.     SIG NXT
  c.d.e.   NXT b.c.d.e. (*.c.d.e. does not exist)
  c.d.e.   SIG NXT

With a few (one or two) intermediate label levels these requirements can,
with some effort be satisfied, though are expensive, especially at the
resolver side. With a higher amount of intermediate levels (bitstring
labels come to mind), these requirements are hard to satisfy due to
message size limits (even with EDNS0) and time-outs.

A second, but weak, motivation to deny wildcards to be used in DNSSEC is
that eventhough unexpanded wildcards are signed, the name part of an
expanded wildcard is not signed. An unsigned name part does not compromise
security though.

A motivation to allow wildcards to be used in DNSSEC is the requirement to
maintain backwards compatibity with RFC1034/5 and the simple fact that
people use wildcards, and thus want wildcards in DNSSEC.

Opt-In can be used as a method to satisfy both sides of the wildcard
issue. Opt-In allows for unsigned nodes in a secured zone, and in this
particular case, wildcards can be left unsigned in a secure zone, and the
requirement (1) and (2) can optionally be dropped by means of a new
proposal.

Roy Arends
Nominum

--
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: Randy Bush <[email-masked]>
Date: Wed, 27 Feb 2002 06:31:27 -0800

> optionally ease the current requirements due to wildcards by means of a

first, with opt in, the term "secured zone" may not be appropriate.  let's
not slip into market-speak or we'll have to send email in ppt :-).

and can you reconcile this with the suggestion that we might only allow
opting out of ns delegations?  or do i remember that idea incorrectly?

randy

---

From: Roy Arends <[email-masked]>
Date: Wed, 27 Feb 2002 18:57:09 +0100 (CET)

> not slip into market-speak or we'll have to send email in ppt :-).

No market-speak intended, lets not throw mud.

> opting out of ns delegations? or do i remember that idea incorrectly?

No. Yes.

We (opt-in authors) expressed individually, separately on this list our
thoughts about "only allow opting out of ns delegations" which generated
no comments from the wg. IMHO only allow opting out of _unsecure_ ns
delegations (instead of allowing any RRset to opt out), has still not seen
a _technical_ argument _for_ it.

The new technical argument (wildcards & opt-in) is a way to reduce the
current requirements and complexity in dnssec.

Roy