Subject: Re: Another NEW technical argument for Opt-In.

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 11 Mar 2002 10:47:42 +0100

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

> 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.
> 

I have always interpreted thing different, could you give me a
reference on how you came to this conclussion. I would like to confirm
that my thinking is wrong.

> 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.

Hmmm (again :-) ) Is that not the wrong solution to the problem. If
you want to secure wildcards in the DNS you should not just exclude
them.

In another message you wrote:
> 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 'restrict opt-in to delegations only' is an _operational_
argument; _operational_ arguments are as valid as _technical_
arguments. Besides silence should not be mistaken with consensus.

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

--
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, 11 Mar 2002 12:17:40 +0100 (CET)

> that my thinking is wrong.

RFC2535:

5.3 Additional Complexity Due to Wildcards

   Proving that a non-existent name response is correct or that a
   wildcard expansion response is correct makes things a little more
   complex.

   In particular, when a non-existent name response is returned, an NXT
   must be returned showing that the exact name queried did not exist
   and, in general, one or more additional NXT's need to be returned to
   also prove that there wasn't a wildcard whose expansion should have
   been returned. (There is no need to return multiple copies of the
   same NXT.) These NXTs, if any, are returned in the authority section
   of the response.

   Furthermore, if a wildcard expansion is returned in a response, in
   general one or more NXTs needs to also be returned in the authority
   section to prove that no more specific name (including possibly more
   specific wildcards in the zone) existed on which the response should
   have been based.

This was where my interpretation was based upon. Since I don't know what
your interpretation is, I can not confirm your current thinking is wrong.

> you want to secure wildcards in the DNS you should not just exclude

There was some discussion on the additional complexity due to wildcards.
In short: much work, little gain, which lead me to another case where
Opt-In is useful: leave cruft unsigned while using DNSSEC. In this case:
wildcards.

Now, if you want to _secure_ wildcards in the DNS, this is obviously not a
solution you want. Nor is there an implementation that supports it yet.

If you want to use wildcards in DNSSEC, opt-in allows you to do that.

> arguments.

Can you state the _operational_ arguments for 'restrict opt-in to
delagations only' ?  That was I was looking for !

> Besides silence should not be mistaken with consensus.

I'm not subjected to false consensus bias or conjecture by the mere
absence of valid arguments on restricting opt-in, I simply noted the
absence of arguments. As said before, lets not throw mud.

Roy Arends
Nominum

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 11 Mar 2002 12:46:00 +0100

On Mon, 11 Mar 2002 12:17:40 +0100 (CET)

> delagations only' ?  That was I was looking for !

http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00104.html and
other messages.

Abstract: Introducing granularity of security will make troubleshooting
verifiers harder. One moves the burden away from the servers to the
clients.

I am afraid that we will follow a path where end users cannot be
bothered to set up verifying resolvers since only the www.bla.foos in the
world are signed and the costs of maintaining is just to
high.

I realize these are not the strongest argument so I do  not want to be
orthodox about them. However, I still wonder why the original designers
choose to work with the concept of secure zones instead of secure names.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 14 Mar 2002 08:43:25 +0100

I think I understand the argument.

> requirement (1) and (2) can optionally be dropped by means of a new

So in other words: If we _require_ the use of opt-in over wildcards we
loose the complexity; wildcard's MUST not be accompanied by SIG and NXT
records.

If the working group requires signatures over wildcard record this
argument looses it's validity as an argument for OPT-IN.

--Olaf

---

From: Roy Arends <[email-masked]>
Date: Fri, 15 Mar 2002 09:51:12 +0100 (CET)

> loose the complexity; wildcard's MUST not be accompanied by SIG and NXT

Yes.

> argument looses it's validity as an argument for OPT-IN.

Yes.

Roy

---

From: Derek Atkins <[email-masked]>
Date: 15 Mar 2002 10:43:02 -0500

If this is the case then an attacker can always force the recipient
to believe a wildcard by replacing any response with an unauthenticated
wildcard response.  I think this is a bad idea.

Eg:

   Query:
        www.foo.com. A?

   Response:
        *.foo.com A 1.2.3.4

How is a client supposed to know that this is an authentic response?
If the server MUST NOT reply with a SIG or NXT, then what's to stop
someone from _creating_ this record and sending it in response to any
query?

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Roy Arends <[email-masked]>
Date: Fri, 15 Mar 2002 17:10:31 +0100 (CET)

> someone from _creating_ this record and sending it in response to any

Security aware resolver asks "www.foo.com. A" and expects a signed
statement (since parent previously claimed foo is secured).

If www.foo.com does not exist, client will receive either

       vvv.foo.com NXT xxx.foo.com NXT SIG
       vvv.foo.com SIG NXT
  (NXT bit set-> not opt-in -> www.foo.com does not exist)

or, with wildcards:

www.foo.com A
vvv.foo.com NXT xxx.foo.com SIG
vvv.foo.com SIG NXT
 (NXT bit clear -> opt-in -> might be some unsigned RRset between vvv and
  xxx)

In my previous answer to Olaf Kolkman, I ment to acknowledge that when you
drop the requirements (1) and (2), wildcards do not exist in the DNSSEC
realm (i.e. unexpanded wildcards do not have a SIG or NXT associated with
them), and you can still use them by means of opt-in, since they may exist
in the unsecure realm.

Roy