Subject: Re: Q-28 Clarification of the scope of the document set.

From: bill <[email-masked]>
Date: Tue, 3 Feb 2004 10:32:16 -0800 (PST)

changes sprinkled throughout, mainly changing "bogus" to "indeterminant",

> In the DNSSEC architecture the security aware resolver determines if
> DNS deta is in one of three states "unsecure", "validated" or
> "bogus". The specification in these document set is designed to make
> sure these 3 states can unambiguously be determined from the answers
> that are returned from security aware servers.

	I'm unconvinced that the resolver makes this choice.
	a design we are working on/with has the validator as
	an independent module that the resolver talks to and
	it is the validator that determines the "state of the data"
	and tells the resolver.  So, alternate text:

 In the DNSSEC architecture a security enabled resolver receives data
 in one of three states, "unsecure", "validated", or "indeterminant".
 The specification in this document set is designed to make sure these
 three states can unambigiously be determined from answers received
 from security aware and enabled servers or caches.
 
> Validated: Data is "validated" if one of possibly multiple
>          authentication chains from a trust anchor to the data itself
>          can be established. Multiple authentication chains can exist
>          when there are multiple DS RRs at a delegation point or when
>          data is covered by multiple RRSIGs.  A security aware resolver
>          may not have all possible authorization chains at its
>          disposal, either because an authorization chain is based on an
>          algorithm that has not been implemented or because there is no
>          trust anchor for a possible authenticatio chain available.
> 
> 
> Unsecure: If no authentication chain can be established; either
>          because there is no appropriate trust anchor or the
>          authentication chain was broken because of the authenticated
>          absence of DS RRs that point to keys of algorithms the
>          resolver is able to use.
> 
>          If there are no trust anchors configured than all data is
>          marked insecure.
> 
> 
Indeterminant: Data that is neither validated nor unsecure: Somewhere in the
        authentication chain, at the time when authentication was tried,  there 
        was an RRset for which all of the RRSIG RRs did not cryptographically i
	verify or were intended for a different time interval. Alternatively not 
	all needed links in the authorization chain were available e.g. because 
	network failures. 

	Recovery or Retry, in an attempt to reach a validated state are
	out side the scope of this definition.
 
> Once security aware resolvers have determined if data is 'secure',
 'insecure' or 'indeterminant' their work is done. This specification does not
> define a format for communicating why data was found to be bogus or
> insecure. For the communication between a security aware recursive
> servers and security aware stub resolvers this specification defines a
> default policy for communicating the 3 states. The detailed
> specification of a method for signaling advanced error codes and or
> policy between a security aware stub resolver and security aware
> recursive nameservers is subject to future work.
> 
> </proposed intro text>
> 
> 
 If the security aware recursive nameserver validates data as "indeterminant"
> it returns an answer with RCODE=SERVFAIL
> 
> 
> --
> 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/>
> 

--
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: Mike StJohns <[email-masked]>
Date: Tue, 03 Feb 2004 14:02:55 -0500

I think you're heading down the wrong direction here.  There are actually 4 
states.  And bogus is definitely a different state than indeterminate and 
can get handled quite differently by a resolver.

1) Secure.  I have a trust anchor, a chain of trust and I'm able to verify 
the signatures on all the data.

2) Unsecure.  I have a trust anchor, a chain of trust, and, at the 
delegation point I have a signed proof of the non-existence of the DS 
record which makes subsequent branches in the tree provably 
unsecure.  Resolver policy could also declare a portion of the tree 
unsecure from a branch point.

3) Bogus.  I have a trust anchor which is giving me an expectation that 
subsidiary data will be signed (e.g. foo.com trust anchor implies that 
bar.foo.com will be signed unless its explicitly unsecure as above),  but 
the data I'm handed fails to validate due to one or more of: missing 
signatures, invalid signatures (both for expiration and for the sig 
algorithm verification), missing data where the NXT (or what ever we're 
call them) say there should be data, etc.

4) Indeterminate.  I have no trust anchor which would indicate that a 
specific portion of the tree is secure.  This is the default case.

Indeterminate and unsecure data should be handled more or less identically 
- e.g. accepted at face value if the policy allows it.   Secure data should 
generally be accepted.  Bogus data - well.... ideally this would depend on 
what the application cares about, but in practice it will be whatever the 
policy is at the caching/recursive resolver.

---

From: bill <[email-masked]>
Date: Tue, 3 Feb 2004 11:15:11 -0800 (PST)

perhaps, but it may just be a desire to keep things "simple". 
	for now, lets presume your four states.  What else is a distingishing
	characteristic?  I see these.

	the bogus lable is primarily driven by temporal events, e.g.
	routing anomolies, head space/timing syncronization, clocking errors,
	etc.

	secure/unsecure presume routing stability, accurate clocks and 
	alert/aware operators.

	indeterminant is todays status quo.

	or do I have this wrong also?

--bill

---

From: Ted Hardie <[email-masked]>
Date: Tue, 3 Feb 2004 12:05:35 -0800

At 2:02 PM -0500 02/03/2004, Mike StJohns wrote:
>Bogus data - well.... ideally this would depend on what the 
>application cares about, but in practice it will be whatever the 

I think I'm confused here.  What do you think the role of the 
application would be?
Are you thinking that on getting an error message back from the DNS, it might
engage in some activity (like throwing an error in a popup or syslog)?  Or
are  you thinking an application policy might actually cause it to accept
bogus data?
			regards,
				Ted Hardie

---

From: Matt Larson <[email-masked]>
Date: Tue, 3 Feb 2004 15:38:36 -0500

Mike,

I think this is on the right track.  A question and a comment:

> unsecure from a branch point.

I'm assuming your "branch point" is a delegation point.  By your last
sentence, are you envisioning the ability to configure a resolver with
the notion thay, say, "Always treat foo.com and its descendants as
unsecure regardless of what security records you receive that might
state otherwise"?  I can see this being a handy feature when a zone is
known to have something wrong DNSSEC-wise but one needs to communicate
with it anyway.  Realistically these scenarios are going to occur.

> - e.g. accepted at face value if the policy allows it.

I'm having a hard time appreciating why anyone would ever care about
the distinction between unsecure and indeterminate.  Or to put it
another way, what different action would be taken based on being in
one of these states vs. the other?  Unless I'm missing something, one
only reaches an unsecure state by discovering a deliberate entry,
i.e., an administrator has to make an entry in a secure zone declaring
a child zone unsecure.  So there's the subtle difference of "someone
went out of their way to say this is unsecure" vs. "I just don't know
its status".  But my question is, is the difference too subtle to be
worth calling out with a fourth state?

Matt

---

From: Rob Austein <[email-masked]>
Date: Tue, 03 Feb 2004 15:43:36 -0500

> are  you thinking an application policy might actually cause it to accept

Given that only the application really knows what the application's
"security" requirements are, final decision on how to handle the bad
states pretty much has to be up to the application.  All the nasty
stuff with the AD bit, etc, is just an attempt to extend -some-
protection to all the legacy DNS software that's already out there.

As I've mumbled before, sig validation is an end-to-end thing between
the DNS data producer (zone admin) and the DNS data consumer (app).

And yeah, sure, an application might have a policy like "the admin of
this zone is known to be an incompetent bozo, and I'm doing a strong
authentication check with known keys at the app layer anyway, so I
don't care whether the DNSSEC sigs check out or not".  Shouldn't be
the default policy, but you can bet that somebody's going to need to
implement something like it sooner or later for some application.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 3 Feb 2004 13:15:58 -0800

>protection to all the legacy DNS software that's already out there.

Assuming there are four states, and using Mike's names for them,
I would say it makes sense to return the data from Secure,
Unsecure, and Indeterminate results to the application layer, along with
a marker as to which of those states the data came.  Over time, with
deployment increases, we would hope that more and more of the data
would transition to Secure and out of Indeterminate.

But Bogus strikes me differently.  Here I would say that a normal
DNSSec-aware call from an app to the DNS should return no data, but
should throw an error saying that the data returned failed the DNSSEC
checks.  There may need to be another routine needed to allow an
application to set the "ravish-me" bits, to use one of our colleague's
colorful phrases, but it seems to me that we should be reaching for a
day in which an application wanting to bypass  those checks should
have to do so explicitly.  I don't see a way to do that if we start out
with the default being an app receiving known-to-be bogus data
and being asked to deal.

A compromise might be to say that the error thrown by Bogus data
should contain the bad data.  Anyone reading the data out of the error
and using it has pretty much got to know they're garbage fishing.

Note that in the long term, I would expect this to be not so much a
DNS protocol issue, but an API issue between the apps and the DNS.

			regards,
				Ted

---

From: Mike StJohns <[email-masked]>
Date: Tue, 03 Feb 2004 17:12:10 -0500

At 03:05 PM 2/3/2004, Ted Hardie wrote:
>>Bogus data - well.... ideally this would depend on what the application 
>>cares about, but in practice it will be whatever the policy is at the 
>>caching/recursive resolver.
>
>I think I'm confused here.  What do you think the role of the application 
>would be?

I'm thinking that I might not care what the DNS is saying if the 
certificate handed to me by the SSL connection I'm initiating is the right one.

The application may want to do the connection (or some other application 
specific thing based on various records such as NAPTR, MX, etc) regardless 
of whether or not DNS says the data is correct, IF (and maybe IFF) it has 
another way of verifying identity.

Later, Mike

---

From: Mike StJohns <[email-masked]>
Date: Tue, 03 Feb 2004 17:26:43 -0500

At 03:38 PM 2/3/2004, Matt Larson wrote:
>I'm assuming your "branch point" is a delegation point.

Mostly yes.  Because the semantics of DS as a secure delegation indication 
is supposedly tied to delegation NS records. Its possible that we may also 
want to consider the case where  the zone is foo.com, *.foo.com are secure 
records, but *.unsecure.foo.com are not and there isn't any actual 
delegation (e.g. its all still part of the zone).  I'm not sure it makes 
sense to consider this case, but that's really what I meant by branch 
point.  I can't think of a case where I'd want to do this, but that doesn't 
mean someone won't come up with a good reason.

>   By your last

Right.  You can know that foo.com is secure, either because you've got a 
trust anchor for .com and .com says foo.com is secure, or you've got a 
direct trust anchor for foo.com.  You may want to override what .com says 
about foo.com by declaring the zone unsecure.

If you don't have a trust anchor for either foo.com or for .com, the zone 
is indeterminate.  Its *possible* that what you want to do in this case is 
collect the top level keys the first time you do a query and then report 
future inconsistencies.  Not saying this is a good idea, but its something 
you could do with indeterminate zones.

>worth calling out with a fourth state?

I think its worth it because I can see the possibility of a policy that 
says "accept only data that's subsidiary to known trust anchors"  secure, 
bogus and unsecure data are all subsidiary to known trust anchors by 
definition.  This basically says, don't accept data from those who don't 
play in the DNSSEC sand box.

Again, I may be over generalizing here, but given the rather limited 
discussion of resolver policy I'd rather do this now than trip over it later.

---

From: Mike StJohns <[email-masked]>
Date: Tue, 03 Feb 2004 17:31:02 -0500

>         routing anomolies, head space/timing syncronization, clocking errors,

Attacks.

>         secure/unsecure presume routing stability, accurate clocks and

No - presume validatable signed data in the DNS that link back to known 
trust anchors.

>         or do I have this wrong also?

No - I think you've got it mostly right, but see the above.  The problem is 
one of relativity.  All of these need to be relative to the querying 
entity.  Its the one making the 
good-secure/good-unsecure/bad-bogus/indeterminate decision and then it 
needs to decide what to do with what it knows.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 3 Feb 2004 15:37:04 -0800

At 5:12 PM -0500 02/03/2004, Mike StJohns wrote:
>The application may want to do the connection (or some other 
>application specific thing based on various records such as NAPTR, 
>MX, etc) regardless of whether or not DNS says the data is correct, 
>IF (and maybe IFF) it has another way of verifying identity.

The problem here is that the actions are serial.  If I get Bogus data from the
DNS and attempt a connection, I have given away some information about
myself that may be going to an attacker.  Even if my later check of the TLS
cert prevents me from shoving my credit card number at the attacker,
I'm still down on the game.

I agree that there will be some conditions where an application needs to try
a connection despite a DNSSEC result of Bogus data, but, as I said in my
message to Rob, I think the app needs to work at it a bit.  From an API
perspective I think getting the result BOGUS_DATA to my "dnssec_dig 
AAAA goodguy.example.com" query is the right answer, even if I can go 
on to
a "dnssec_dig -ravishme AAAA goodguy.example.com" to get the data anyway.

Again, I think this is long term an API issue, not a protocol issue, but I
want to make the point that at least one APPs guy would like to see Bogus
data as an error to the APP unless the APP has specifically allowed it.

Just my opinion, of course,
			regards,
				Ted Hardie
is the r