Subject: opt-in and wild card discussion

From: Edward Lewis <[email-masked]>
Date: Thu, 25 Aug 2005 22:29:55 -0400

In reference to 
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01162.html:

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

I suppose the answer to the first question is yes.  That is, there is hope.

I recall a conversation amongst those of us working in close quarters 
in the early days (close quarters meaning, in office, hence nothing 
in email) on the purpose of DNSSEC.  One opinion was that DNSSEC was 
meant solely to say that what goes into the master server comes out 
of the resolver - no changes, no deviations.  The contrasting opinion 
of the day was that the resolver would return the data it received 
along with some measure of surety of the data so that the application 
could act accordingly.

Of those two opinions, a consensus was and has never been achieved, 
at least explicitly.  I think that it is unfortunate, because 
settling this would have gone a long way to defining the "finish 
line."

A third opinion was floated and discarded, that DNSSEC assured the 
accuracy of the data.  If the administrator of the DNS mistyped the 
IP address in an address record, DNSSEC would not fix this.

So, for (a), there is no "correctness" principle in DNSSEC, in the 
sense of data correctness.

Uniqueness is not an accurate adjective to apply to a DNS answer, 
much less an DNSSEC answer.  DNS strives for coherency, meaning that 
if you ask any source in the distributed database you should get the 
same answer.  When you combine caching and the lack of a time element 
(recall that in protocols pre-NTP we avoided time like the plaque), 
coherent answers aren't guaranteed to be unique in that coherency is 
meant "at a point in time" and "not for all time."

DNSSEC did not set out to fix that design point in DNS.  Although 
DNSSEC adds the notion of (absolute) time, it is still falls short of 
being a versioning time stamp of data.  E.g., we have never bothered 
to hammer out the semantics of an RRSet signed for Monday and 
Wednesday in two different signatures, and the same set with a 
different value signed for Tuesday.

So, for the other half of (a), DNSSEC does not guarantee uniqueness.

Moving on to (b), there is no guarantee that a correct signed reply 
will be accepted by a correctly functioning requestor.  DNS in very 
much wedded to UDP and all that unreliable datagram transports 
entail.  There is no session or higher layer contract between client 
and server in the protocol.

(For reference, see RFC 3090, which discusses the state of a zone in 
the eyes of DNSSEC.  Although it is quite dated with respect to the 
DS record and type code roll, the concepts hold up.)

In my view, DNSSEC is all about the resolver building trust in an 
answer.  The role of the zone is to provide enough data to allow the 
resolver to do this.  A correctly functioning resolver is, at all 
times, permitted to "follow local policy."  This could entail, for 
example, trusting a public key distributed be a so-called "alternate 
root" administration, not trusting any public key, trusting a 
"look-aside" key (meaning a key owned by a domain that is not a 
parent of the target data).

All that a zone administrator (represented by a server) can do is 
meet the conventionally known standards of securing a zone (as in 
3090) while also minding the policies of the "resolvers of interest." 
A zone can expect no more - for example, DNSSEC does not defend 
against a flood of unwanted traffic preventing the server from 
hearing earnest queries.  All a zone owner can expect to achieve is 
offering ancillary data to allow the resolver to make its own 
judgement.

So - if a local policy is to trust the public key of a so-called 
"alternate root", data signed by a zone conforming to the 
"non-alternate" root will be rejected by the resolver.  Hence, the 
answer to (b) is no.

For (c) and (d), we have to drop the premise of "correct."  But the 
other parts of the questions I'll address.

(c) Can a signed answer be substituted for an unsigned answer.  Let's 
assume that, having a comprehensive view, an RRSet is supposed to be 
unsigned.  Also, let's assume that a conventional root is in use and 
it is signed.  In this case, at some point there ought to be a 
delegation point that can prove there is no DS RRSet.  (This is why I 
believe, much to the chagrin of Mike St. Johns that authenticated 
denial is a must have feature of DNSSEC.)  In this case, a resolver 
can retrieve the chain of DS RRSets, NSEC RRSets, and keys, needed to 
see that the desired data is outside of the island of security.

Keep in mind that the RRSet may still be (validly) signed, but the 
signature is useless to the resolver, and DNSSEC is all about the 
resolver.

(d) Similar to (c), a resolver ought to see a sequence of DS RRSets 
to the desired data.  Assuming no cryptographic algorithm problems, 
the resolver ought to build up an expectation of seeing security data 
(RRSIG).  One of the first rules in security is that the environment 
ought to meet expectations.

(Is the second (d) the same as (c)?)

Now, for the after-questions.

DNS is to be modeled (but not necessarily implemented) as a 
graph-theory tree on a two dimensional plane, with data sets 
orthogonal to the plane of the tree.  (My math terminology has gotten 
rusty over the years.)

Domain name are "paths" or "routes" from the root of the tree to some 
location in the data space.  (This is fairly explicitly said in RFC 
1034.)  The look up algorithm in the infamous 4.3.2 of 1034 makes it 
clear that looking for a name is done first by travelling the tree 
"down" to the end of the domain name's indicated path.  (Because 
there is an absolute start, there is no distinguishing between a 
route or address.)

Once the right address in the tree is determined (that includes 
CNAME, DNAME, and wildcard synthesis), the types are consulted. 
"Types" exist in another dimension, if you will.

As far as message passing amongst protocol elements, it is considered 
to be untrustworthy.  DNSSEC, as defined in RFC 403x makes no 
guarantee of message security, just DNS(SEC) element to DNS(SEC) 
element security.  Message security is addressed (in one fashion) by 
TSIG and SIG(0).  Whether or not the latter concepts are part of 
DNSSEC is open to debate - albeit an academic debate.

I think the biggest technical obstacle to DNSSEC, speaking in 
hindsight, is that DNS seems to promise a clear line of authority 
over records (the zone concept), but the promise is not met by the 
message structure (lack of authority for all the names in a CNAME 
chain), not met by the delegation mechanics (authority for the NS 
existence is by parent, contents by child), and not by the 
operational agreements of the DNS.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 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
>     requestor that receives the reply
>(c) no incorrect signed reply can be undetectably subsituted 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

---

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