Subject: resurrecting wildcards and opt-in

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Aug 2005 08:42:37 -0400

Referring back to:

http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01745.html

Since that post a WG draft on wildcard clarifications (and 
modifications) has progressed from an individual -00 to an 
all-but-completely-edited-post-wglc document.  (Really, it is.  I am 
waiting on one vacationing person to review section 4.2.1.  They know 
who they are.)  I mention this because we have a collectively higher 
consciousness about wild cards now.

My hypothesis is that the crucial question is - in an opt-in zone, 
can any RRSet (signed or unsigned) cause ambiguity over the security 
of another signed RRSet in the same zone?

I'll start with arguing over the question.

The objective of DNSSEC is to make sure the client (resolver) can 
detect if an RRSet has been protected and has arrived safely.  First 
it is important to tell if the RRSet has been protected - my that I 
mean the resolver can follow a chain of trust right to the RRSet. 
Second, if the resolver has an expectation that the RRSet is to be 
secure, the resolver can then inspect the security meta-data to 
verify the RRSet.

Unprotected data, meaning data not signed via DNSSEC, cannot be 
verified within DNSSEC.  (I'll leave it to the philosophers and sages 
to argue over other forms of verification.)  Unprotected data does 
not prevent protected data from being verified.  The upshot is that 
DNSSEC does not help unprotected data, and DNSSEC should "survive" 
unprotected data.

The reason I mention this is the question of what happens with a 
signed wild card RRSet in a zone that allows for unsigned RRSets.  It 
is trivial to present a properly signed wildcard synthesized RRSet 
without having access to the private key needed to generate the 
signature.  An unsigned RRSet has no defense against that attack.  A 
signed RRSet has a defense - the falsely synthesized RRSet has to be 
accompanied by other signed RRSets that do require access to the 
private key.

It is true that opt-in opens the door to a falsely generated signed 
wildcard synthesis being used to spoof an unsigned RRSet in the same 
zone.  But so far I don't see that as a problem given that the 
unsigned RRSet is no worse off than today.

Complicating the matter, it is possible that the closest encloser of 
a query name be unsigned (assuming the query name does not exist in 
the modified sense of RFC 1034).  In this case, a signed wildcard 
synthesis may be presented maliciously instead of a return code of 
name error or NXDOMAIN (provided the wild card domain name otherwise 
"covers" the query name.

I think this is an interesting case.  If there is no synthesis to 
apply to a query name that does not exist, then there is a signed 
NSEC record to return.  With synthesis, there are no name errors.  So 
what happens with an unsigned RRSet prevents the application of 
synthesis?

Maybe this is a problem.  A resolver might see an unsigned NXDOMAIN - 
which would be the proper answer if there was an unsigned closest 
encloser between a signed wild card and query name.  Without an 
attack, how does a server indicate that there is an unsigned closest 
encloser?

I'll stop there.

Here's a zone illustrating the problem:

$origin example.
@       IN  SOA       <soa data>
             RRSIG     SOA ...
             NS        ns0.tld. ; so I don't need A / AAAA records
             NS        ns1.tld.
             RRSIG     NS ...
             DNSKEY    #1
             DNSKEY    #2
             RRSIG     DNSKEY ... #1 ...
             RRSIG     DNSKEY ... #2 ...
             NSEC      * ...
             RRSIG     NSEC ...

*           TXT       "This zone has a wildcard"
             RRSIG     TXT ...
             NSEC      alpha ...
             RRSIG     NSEC ...

alpha       A         127.0.0.1
             RRSIG     A ...
             NSEC      crouton ...

bacon-bits  AAAA      ::0 ; an unsigned entry

crouton     AAAA      ::1
             RRSIG     AAAA
             NSEC      example.
             RRSIG     NSEC

;

What is the answer to this query?

QNAME = i.want.my.bacon-bits.example.
QCLASS = IN
QTYPE = RP

DO flag on...CD on...

Do I have to put the bacon-bits AAAA RRSet in the answer to explain 
this to the resolver?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

--
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: Edward Lewis <[email-masked]>
Date: Thu, 18 Aug 2005 11:08:38 -0400

At 8:42 -0400 8/18/05, Edward Lewis wrote:

>Do I have to put the bacon-bits AAAA RRSet in the answer to explain this
>to the resolver?

It's been pointed out that only delegations can be in unsigned spans. 
So this won't happen.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Tue, 23 Aug 2005 12:46:46 -0600

The discussion has been interesting.  It sounds like we need "An
Elementary Introduction to the Theory of DNS and DNSSEC".  Is there
some hope of a simple and verfiable set of rules for the requestor and
responder from which one could prove that

(a) there is a unique, correct reply to any query 
(b) a correct signed reply will be accepted by a correctly functioning
    requestor
(c) no signed reply can be undetectably subsituted for 
    the correct signed reply
(d) no unsigned reply can be undetectably substituted for the 
    correct signed reply
(d) no signed reply can be undetectably subsituted for a correct unsigned reply

 ?

How does one go about proving (a)?  Can DNS be modeled as a set of
sets with a lattice structure (to accommodate wildcards)?

Does the proof need to assume that messages can be inserted but not
deleted from the channel?  Or can one assume complete channel control
by the attacker?

Hilarie