Subject: Re: opt-in and wild card discussion

From: Edward Lewis <[email-masked]>
Date: Fri, 26 Aug 2005 15:51:24 -0400

At 10:16 -0600 8/26/05, Hilarie Orman wrote:
>Thanks for your answers.  I think they are slightly larger than my
>questions, though.  The context is simply between two entities, a
>requestor and a responder (not a requestor and a distributed
>database), and when I saw "accept" I mean "if received, will be
>accepted as a corect".  And "the second (d)", which should be (e),
>differs from the previous (d) by two characters ("un").
>And by "accept" I mean "can establish a chain of trust".

I'll quibble with the term "correct" and substitute "authentic."  In 
the sense that the administrator could have made a typographic error. 
I suspect this isn't the detail you refer to, but I have a knee-jerk 
reaction to the word "correct" in the context of DNSSEC.

Overall, the answer is no.  In the pure theoretic sense, there is no 
covenant between requestor and responder.  A requestor's right to a 
local policy prevents any guarantee.  In practice, there will 
probably be a covenant provided by the producer of the software in 
use - e.g., "burning in" a trusted key for the (a) root zone.  (I 
leave this open to cover cases in which DNS implementations are used 
in spaces not associated with the Internet.)

>Your discussion of the tree of records gets at the heart of the
>matter (btw, "2-D tree" is redundant).  This model may be OK
>for DNS-nonSEC, but there are several more rules for DNSSEC.
>It's the formalization of those rules and the modified lookup
>rules that I'm hoping to nail down.

Ironically, I did twinge when I decided to add "2-D" as an adjective 
of the tree.  I meant that in the sense that I envision the tree as 
being drawn on a flat piece of paper, with the RRSet's sticking up 
like little flags.

I suppose what you are referring to is the authorization model, which 
originally was to be more flexible (RFC 2065).  RFC 3008 was the 
first documentation resulting from our frustration with a flexible 
authorization model, RFC's 4034, et.al., encode a rule that the 
signer field has to be the zone name.  There was a DARPA research 
effort to examine a more flexible authorization model, I don't know 
what results it produced.

The running assumption today is that the authorization space is 
isomorphic to the data (zone) space.  There are proposals to "break" 
this, but for the better part of the last decade no one has spent 
considerable time studying an "alternate authorization" model. 
Certainly, no one has been successful in deriving one that is both 
easily understood and more flexible than what we do now.

>I'll restate the questions with clarifications:
>
>(a) for any responsder, there is a unique, correct reply to any query
>(b) a correct signed reply will be accepted by a correctly functioning
>     requestor that receives the reply
>(c) no incorrect signed reply can be undetectably subsituted for
>     the correct signed reply
>(d) no unsigned reply can be undetectably substituted for the
>     correct signed reply
>(e) no signed reply can be undetectably subsituted for the correct
>     unsigned reply
>
>For the time being, I'll assume a stable world, so that the keys and
>chains of trust are stable.  If they are changing, then the everything
>is predicated on "assuming the requestor obtains data establishing
>a chain of trust wrt to the base query".
>
>All answers should be qualified wrt
>
>NSEC/NSEC3/(NSEC and/or NSEC3)/opt-in/DLV/bogus message insertion/message
>deletion/
>
>of course.

I'll take (a).

The answer is no.

For one, there is no reason that resolvers will have a common notion 
of the trusted root zone, hence a common set of trusted keys.

Secondly, even if all resolvers believe in one root zone, it is 
possible that two caches each have different answers to a query. 
Case 2a, the "QTYPE=any" query.  Case 2b, because of caching, it is 
possible that one cache has one version of an answer and another 
another.  Both may validate under the rules of DNSSEC.

For (b,c,d,e), if I may qualify the question to say "For a particular 
resolver with a trusted key set enabled", and I define "correct" as 
"succeeding in validation with the resolver's trusted key set," the 
answers are yes.

DNSSEC is all about the resolver's perspective.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Fri, 26 Aug 2005 23:57:05 -0400

At 14:59 -0600 8/26/05, Hilarie Orman wrote:
>My questions really are smaller than your answers.

Okay...

>>  (a) for any responder, there is a unique, correct reply to any query
>
>This isn't a question about whether or not a resolver will accept
>the response as authentic or consistent with local policy, it is
>about describing the correct behavior of the server.

As far as the server is concerned, RFC 3090 documents that.  The RFC 
is pre-DS RR and uses the old RR types.  But if you pull out the 
parts that refer to the RR types, the concepts still hold, I think.

But, DNSSEC is still in the eye of the resolver.  The server-side can 
only hope to configure itself "correctly."  That's what RFC 3090 
means by globally and locally secured.

>For the other questions, "accept" only means that a chain of trust can
>be established.  Maybe "validate" comes closer.  A resolver that
>accepts and uses provably bogus answers isn't the kind of resolver
>that I'm asking about --- it doesn't "validate" wrt to a model.  As
>far as I know there are only two models under consideration for the
>resolver: from-trusted-root, and from-trusted-nonroot.

Yes - "a" chain of trust can be established.  But be careful, an 
answer might arrive with a RRSIG is immaterial.  Such an answer is to 
be considered unsigned.  Immaterial means that the resolver doesn't 
have a trusted key that would lead to the RRSIG.

>Caching is irrelevant here, because if there is no question, then one
>can hardly complain that the answer is wrong.

I figured that if you want a true model of DNS(SEC), you need to be 
aware of caching.  Caching has proven to be tricky.

>I'm looking for minimal set of formal rules that will assist a
>mechanistic answer to the questions.  If the rules exist, then it
>should be possible to answer many questions about both the security of
>DNSSEC wrt to attacks and its perceived complexity.  Perhaps these
>rules exist in the compendium of all RFC's pertaining to DNS - but
>how about something smaller than my head?

It would be interesting to see someone spend the time to do that...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar