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: Alex Bligh <[email-masked]>
Date: Mon, 29 Aug 2005 08:54:55 +0100

--On 25 August 2005 22:29 -0400 Edward Lewis <[email-masked]> wrote:

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

I think I'm even less ambitious than that. I thought the idea was that IF a
resolver made a query AND received a reply, it could determine whether (i)
the resolver ought to have expected a signed reply, and (ii) whether that
if the reply WAS signed, it was signed a key possessed by an authoritative
server. No more, no less.

That's a bit different from the first opinion, as it worked on the
presumption that DNSSEC would not prevent denial of service attacks (either
packet loss, or through injection of SERVFAIL etc.) and (less
significantly) presumption of continuing legacy support. It also means
DNSSEC is not in itself responsible for ensuring security of private keys
etc. Perhaps that's why I'm less worried about opt-in than some.

Alex

---

From: Edward Lewis <[email-masked]>
Date: Mon, 29 Aug 2005 08:59:25 -0400

>etc. Perhaps that's why I'm less worried about opt-in than some.

I don't think there is a semantic difference between the first 
opinion and what you describe, but there is a syntactic difference. 
I failed to comprehensively capture the old conversation - things 
like denial of service attacks weren't part of the thought then.

What was meant by "what goes in" and "what goes out" referred to the 
extent of the protection, i.e., DNSSEC would not go up into 
application space.  (This is describing the first opinion, not a 
consensus.)  Perhaps what I should have said was "what goes out" is 
"what went in" and not the other way around.

The syntactic difference is steps i and ii are one way to carry out 
the mission, and although that is how we have approached it, that was 
more detail than the conversation had at that time.  (I mean, we were 
already writing code, the conversation was just "higher level.")