Subject: ahh, the dreaded opt-in discussion again

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Oct 2002 16:09:47 -0400

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.

E.g.,

Let's say I have the following names in my zone:

*      -- signed (synonymous with opt-in)
dele-a -- signed
dele-b -- unsigned (eg opt-out)
dele-d -- signed

You will notice that there is no dele-c, that name would match the wildcard.

If QNAME=dele-c, you should see an answer:

dele-c   ANSWER="*"
dele-c   SIG (ANSWER)
dele-a   NXT dele-d with opt-out names
dele-a   SIG (NXT)

But you could see the following illegal answer:

dele-c   ANSWER=bogus match
dele-a   NXT dele-d with opt-out names
dele-a   SIG (NXT)

Of course, if QNAME=dele-b, I should get:

dele-b   ANSWER=dele-b's data
dele-a   NXT dele-d with opt-out names
dele-a   SIG (NXT)

but I could get this illicit answer:

dele-b   ANSWER="*"
dele-b   SIG (ANSWER)
dele-a   NXT dele-d with opt-out names
dele-a   SIG (NXT)

Of course, dele-b is vulnerable to attack because it is unsigned, but 
in the latter case, it looks like the answer is signed.

The problem lies in that the explicit presence of a name trumps 
whether a name is opt-in.  Another part of the problem is that DNSSEC 
signatures do not cover the substitution of the QNAME in the wildcard 
match in the ownername.  It is a simple replay attack to take an 
existing copy of a wildcard expansion and throw in the latest QNAME 
and reply with that.

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?

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?

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.

If nondelegations can be opted out, then we could have an opt-out 
wildcard that itself isn't a delegation.  (Opt out wildcard 
delegations are legal but quite odd.  There's little reason to worry 
about them.)  In this case, all NXT's in the scope of the wildcard 
have to be marked as opt-out capable NXT's.  (Because the wildcard 
makes all possible domains in the scope of the wildcard present.  If 
there were *.com, then there'd never be an NXDOMAIN from .com.)

(I think I'm missing a part of the argument here.  Perhaps someone I 
spoke to can chime in, or remind me privately.  I don't want to hold 
this up anymore than I have.)

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

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

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.

If server policy is to trust what's on it's disk, is it allowed to 
set AD (as according to the AD bit draft)?  Personally, I'd rather 
see the AD bit be twisted to point to the presence of OPT records 
detailing the status of RR sets in the message - the alleged SMB 
proposal.  Note: Maybe I have the proposal wrong, the only way I've 
heard of it is through "the telephone game."

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

There have been attempts in the past to achieve in DNSSEC what opt-in 
is trying to do.  Experimental zones were around for a while, but 
became problematic.  Being able to change signing keys - even 
converting to a NULL key - was around for a while.  Each time we've 
tried this before, it didn't work out because we couldn't make the 
verification process simple enough.

However, it would be wrong to say that the previous failed attempts 
to have partially signed zones means that opt-in is doomed.  A lot of 
DNSSEC as defined  back then has been rewritten having undergone 
wider review.

I'll refrain typing in the ascii art of the opt-in decision tree.  I 
don't think that it would as helpful now, and it's not worth the time 
yet...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

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

> restricted to delegations.  This is related to the presence of a

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

-derek

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

---

From: David Blacka <[email-masked]>
Date: Fri, 25 Oct 2002 17:26:37 -0400

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

> restricted to delegations.  This is related to the presence of a

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?

> delegation information in the answer section (QTYPE="any", as in dig

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

> undermined signed wildcards.)

Ok.

> cannot equal any owner name.

Good point.

> is that QoS in bandwidth services runs counter to the aim of the

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

---

From: David Blacka <[email-masked]>
Date: Sun, 27 Oct 2002 16:03:05 -0500

> think I was drawing any conclusions, I certainly didn't intend to do 

I apologize.

My only point was that this conflict is not a protocol-level ambiguity.

> the process is properly recorded for posterity.

I'm not sure where you are going with this.

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

It isn't significant.

 From the draft:

delegation: refers to a NS RRset with a name different from the
       current zone apex (non-zone-apex), signifying a delegation to a
       subzone.

So, yes, it is the NS RRset.

> response with no answer records, and NS RRset (plus DNSSEC records) in 
> the authority.  (Minimum definition - not accounting for glue in 
> additional.)

The only reason to link delegation to referral is so that the document 
may refer to them interchangeably.  The whole reference to "referral" 
could be removed, since it is probably generally understood what one 
is.  Or the a more explicit definition could be used, like the one you 
suggest.  Whichever is clearer.  So which?

---

From: Edward Lewis <[email-masked]>
Date: Sun, 27 Oct 2002 13:43:59 -0800

At 16:03 -0500 10/27/02, David Blacka wrote:
>... this conflict is not a protocol-level ambiguity.

Yeah, it's clearly an aspect of the proposal, not an issue in it. 
But this aspect may make some people uncomfortable with the proposal.

I'm not insinuating that I'm uncomfortable with this aspect.  Just 
making the fact that the conflict between signed wildcards and opt-in 
a little bit more obvious to those that might have a strong opinion.

>I'm not sure where you are going with this.

E.g., a lot of times we go over the same ideas again and again. 
(Deferred dynamic delete, to pick an example not related to opt-in.) 
It's good to allow the next generation of proposers to see why 
previous attempts failed.

>The only reason to link delegation to referral is so that the document may
>refer to them interchangeably.  The whole reference to "referral" could be
>removed, since it is probably generally understood what one is.  Or the a more
>explicit definition could be used, like the one you suggest.  Whichever is
>clearer.  So which?

Referrals and delegations are two very different things, so I would 
discourage interchanging them.  A referral is an interpretation of a 
response message.  A delegation is an administrative boundary in DNS, 
with that term overloaded to mean the RR sets at a domain name that 
is a boundary.

So, if you can avoid the use of the two interchangably, that's good, 
and hence there's no need to include the definition.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer