Subject: Re: ahh, the dreaded opt-in discussion again

From: Derek Atkins <[email-masked]>
Date: 25 Oct 2002 16:58:34 -0400

Edward Lewis <[email-masked]> writes:

<excellent example of opt-in v. wildcard issues removed>

This is true.  Roy and I were looking at this problem in Yokohama.  I
don't have a good suggestion for a way around this.  I think the
opt-in proponents would say "the zone administrator may shoot
themselves in the foot if they wish, so they should be educated about
the risks of using opt-in and wildcards."

> Another observation made was that opt-in will only work if it is
> restricted to delegations.  This is related to the presence of a
> wildcard.

Luckily we agreed long ago to make this restriction.  :)

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

--
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: David Blacka <[email-masked]>
Date: Fri, 25 Oct 2002 17:26:37 -0400

On Friday 25 October 2002 04:09 pm, Edward Lewis wrote:
> Sooner or later, it has to come to this, sigh.
>
> (Let's see how many spam filters reject a message about opt-in.)
>
> Last week I had a discussion with David Blacka about opt-in.  During
> the discussion the following observation was made:
>
> In an opt-in zone, a signed wildcard is vulnerable.  There is a
> conflict between  domains that are opt-out and a signed wildcard.  Of
> course, the opt-out domains are vulnerable to anything, but that is
> no different that today.  Signed wildcards, which are supposed to be
> protected can be made to appear to not apply.

> Debate: do we just live with this because "who in their right mind
> would use BOTH wildcards AND opt-in in the SAME zone?"  Or do we try
> to fix this?  Or do we kill opt-in?

I don't think there is a problem with using opt-in and wildcards in the same 
zone.  If using opt-in is acceptable, then the fact that wildcards could be 
spoofed away should not bother you.  This is a natural consequence of opt-in 
allowing attackers to insert, modify, or delete insecure names within the 
opt-in span.  (If an attacker inserts an insecure name, then it blocks the 
wildcard.  If the attacker removes an insecure name, then the wildcard will 
look ok.)

If you *depend* on the wildcard not being able to be spoofed away, don't use 
opt-in.  But there are probably many uses of wildcards that don't require 
that level of security.  Actually, I can't think of any uses that would 
require this level of security, but I have a hard time thinking up real uses 
for wildcards period.

Ed, the problem you are having is a human perception problem, not a protocol 
problem.  Because the wildcard record has a signature record, you as a DNSSEC 
research have an expectation that it can't be spoofed away.  But software 
implementing opt-in wouldn't have that expectation.

> Later on, we had a long discussion on whether this means that there's
> never a reason to try and prove the nonexistence of wildcards in
> NXDOMAIN responses.  Hey, what's the value of proving the wildcard
> doesn't exist if it's been undermined anyway?
>

I'm not positive that this is true, but it doesn't matter.  The proposal on 
the table is delegation only, so why burn brain cycles thinking about 
non-delegation-only  opt-in?

> On to the more immediate draft...
>
> Another observation is that when a query is answered, there are three
> outcomes: an answer, a signed NXT denial, or a traditional no answer.
> Now, an answer can be signed (opt-in) or not, but in either case it's
> an answer.  The reason I'm mentioning this is that I'm trying to find
> if there's some patter to opt-in that might make it easy to identify
> corner cases.  (The three way pattern also appeared in the kinds of
> delegations in an opt-in zone - secured, unsecured, and opt-out.  The
> middle one has no DS RR but has an NXT RR.)
>
> Nit: In the definition for delegation - a delegation in a response
> isn't always a referral.  That's a definition thing, I can have
> delegation information in the answer section (QTYPE="any", as in dig
> @a.gtld arin.net any).

Sure.  I buy that.  How about that a delegation in a response *may* be called 
a referral?  or is sometimes called a referral?

> Section 3.1.3: "For both non-existent name (NXDOMAIN)
>     responses and Opt-In insecure delegation responses, servers MUST NOT
>     return negative wildcard proof records when the query name (qname) is
>     covered by an Opt-In tagged NXT record."
>
> That sentence is a problem.  Besides a MUST->SHOULD change, I'd
> rearrange it to this:
>
> For non-existent name (NXDOMAIN) responses when the query name
> (qname) is covered by an Opt-In tagged NXT record, servers SHOULD NOT
> return negative wildcard proof records. (This harks back to the
> undermined signed wildcards.)

Ok.

> For Opt-In insecure delegation responses, there shouldn't be a need
> to even consider any wildcard proofs.  I'm assuming that the response
> is positive.
>
> Section 3.2.4.:
>        sending a non-existent name (NXDOMAIN) response where the covering
>        NXT is tagged as Opt-In, unless the NXT record's owner name equals
>        the qname.
>
> The "unless" part can be dropped.  If you are sending NXDOMAIN, qname
> cannot equal any owner name.

Good point.

> Opt-in is beginning to seem more like a Quality of Service of DNS.
> QOS for bandwidth has problems - as Randy Bush said at a DARPA PI
> meeting panel last January, QoS means dropping packets in favor of
> other packets.  The problem is that dropping packets is not what
> providers are there for.  (I may have part of this wrong, the essence
> is that QoS in bandwidth services runs counter to the aim of the
> service.)

I don't think this analogy works.  Denial of existence of non-existant names 
(which is essentially what you give up with opt-in) is not exactly DNSSEC's 
core mission.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: Paul Vixie <[email-masked]>
Date: Fri, 25 Oct 2002 22:01:46 +0000

> > Opt-in is beginning to seem more like a Quality of Service of DNS. ...
> 
> I don't think this analogy works.  Denial of existence of non-existant
> names (which is essentially what you give up with opt-in) is not
> exactly DNSSEC's core mission.

It's not (yet?) possible to say what is or is not DNSSEC's "core mission."

In other words, there are likely to be folks who need secure NXDOMAIN to
help detect spoofing in other applications or layers, and to them, DNSSEC
without secure denial of existence would add no value, and so they might
claim secure NXDOMAIN as being exactly DNSSEC's core mission.  Until and
unless we have some kind of consensus around some kind of threat model and
applicability statement and mission statement, DNSSEC's "core mission" is
whatever people think it is or want it to be.

In that light, it's amazing that we're stalled so far from where we began.

---

From: Rob Austein <[email-masked]>
Date: Fri, 25 Oct 2002 19:51:59 -0400

I hope to get an updated version of draft-ietf-dnsext-dns-threats out
next week.

---

From: Edward Lewis <[email-masked]>
Date: Sun, 27 Oct 2002 13:19:39 -0500

>implementing opt-in wouldn't have that expectation.

Let's not get personal.  I just stated the observation that (goals of 
a) signed wildcards and (implications of) opt-in conflict.  I don't 
think I was drawing any conclusions, I certainly didn't intend to do 
so in the message.

>non-delegation-only  opt-in?

To make sure we are making the right engineering decisions, and that 
the process is properly recorded for posterity.

>a referral?  or is sometimes called a referral?

I'm not sure why this is significant.  (What is meant by "a 
delegation in a response?"  The NS RRset?)

If you are trying to define a referral message, then just do that - a 
response with no answer records, and NS RRset (plus DNSSEC records) 
in the authority.  (Minimum definition - not accounting for glue in 
additional.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer