Subject: DNSSEC - Intermediate Validation - Good or bad idea?

From: Mike StJohns <[email-masked]>
Date: Sun, 26 Nov 2006 20:41:57 -0500

During my presentation at the IETF I got the idea from the questions 
I fielded that the issue of DNSSEC intermediate validation should be 
treated as a separate issue from PNE vs SO DNSSEC.  For the purposes 
of this thread, I'm taking "intermediate validation" to mean any 
configuration where a end-application is non-DNSSEC aware, but the 
DNS server which handles its recursive lookups is DNSSEC aware and 
can be (is?) configured by policy to block "bogus" responses to 
queries from being sent back to the end-application.

My characterization of this is that the intermediate resolver is 
synthesizing and returning "does not exist" answers for a portion of 
the DNS tree which is subordinate to a trust anchor, but for which a 
DNSSEC proof of existence (or a proof of non-existence for a 
delegation DS record) can't be accomplished.

The counter argument to doing this is that the intermediate validator 
doesn't have enough information to make a good policy decision on 
what to do in this situation.  The validator would need additional 
information about why the DNS question was being asked to do the 
"right" thing. E.g. blocking the data for an HTTP connection might be 
the right idea, but blocking it for HTTPS is probably the wrong idea 
because the underlying TLS connection has a better validation scheme.

One of the attacks on PNE DNSSEC would be a deletion attack on the 
proof that a sub zone wasn't signed.  In this case, perfectly valid 
data that should have been returned would be blocked by policy.

In general, the IETF and others have come down on the side of 
"synthesized answers bad" side of the argument when discussing things 
like "Sitefinder".  Is there a meaningful way to differentiate that 
general concept of answer synthesis from DNSSECs concept?

If there isn't, does the concept of intermediate validation continue 
to be reasonable for any version of DNSSEC?

Mike

Mike

--
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: Mark Andrews <[email-masked]>
Date: Mon, 27 Nov 2006 15:55:05 +1100

> delegation DS record) can't be accomplished.

	I think that a better characterisation is "temporary failure"
	is returned.   Most resolver libraries already distingish between
	"NODATA",  "NXDOMAIN" and "SERVFAIL".
 
> because the underlying TLS connection has a better validation scheme.

	I would agree that the intermediate validator doesn't have enough
	information to make a good policy decision.  That's why its policy
	is conservative.  That is also why DNSSEC validation should be
	done in the clients.
 
> data that should have been returned would be blocked by policy.

	For a m-i-m attack there is little that can be done.  For
	a injection attack the validator just needs to wait for a
	valid response from the authoritative servers.  That of
	course raises other issues.
 
> general concept of answer synthesis from DNSSECs concept?

	Sitefinder was bad because of the place within the heirachy
	that the synthesis was occuring not because synthesis itself
	is inherently bad.  Trust was violated in the Sitefinder case,
	(unwritten) expectations were not met.

	Unfortunately enumerating all the expectations in advance is
	often a difficult task.

> to be reasonable for any version of DNSSEC?

	Yes, I still think it has merit.  The expectation is that data
	entered is what will be returned.  We do know that there are
	people who will attempt to inject bogus data today.  I'm looking
	forward to the day when most such attempts will fail.

	Note: we may still need to sign glue (A/AAAA/NS) from the parent
	zones to prevent caches from being misdirected even if they won't
	return the answers from being misdirected.
	
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Scott Rose <[email-masked]>
Date: Mon, 27 Nov 2006 08:21:39 -0500

Mike StJohns wrote:
<snip>
> doesn't have enough information to make a good policy decision on what 
> to do in this situation.  The validator would need additional 
> information about why the DNS question was being asked to do the "right" 
> thing. E.g. blocking the data for an HTTP connection might be the right 
> idea, but blocking it for HTTPS is probably the wrong idea because the 
> underlying TLS connection has a better validation scheme.
> 
Sometimes this is true, and sometimes it isn't.  In some organizations, 
a centralized policy at the caching resolver is easier to implement than 
upgrading all the stubs.  Since all of the stubs will be following the 
same policy, it is easier to deploy and manage at the recursive server 
than the stubs.

However, for roaming and solo DNS clients (whose upstream cache does not 
belong to the same administrative entity), it makes sense to have the 
end user do its own validation.  And eventually, validation would be 
pushed down to all end users as upgrades are performed.

> One of the attacks on PNE DNSSEC would be a deletion attack on the proof 
> that a sub zone wasn't signed.  In this case, perfectly valid data that 
> should have been returned would be blocked by policy.
> 
> If there isn't, does the concept of intermediate validation continue to 
> be reasonable for any version of DNSSEC?
> 

For some, it is reasonable to view intermediate validation as a stepping 
stone along the deployment path.

Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnssec-deployment.org/
-----------------------------------------

---

From: Edward Lewis <[email-masked]>
Date: Mon, 27 Nov 2006 09:29:26 -0500

At 20:41 -0500 11/26/06, Mike StJohns wrote:

>.........., does the concept of intermediate validation continue to

It is okay for an intermediate server to not check the answers it 
passes back, but it ought to validate any DNSSEC data before 
assigning the data a trustworthiness (RFC 2181, 5.4.1) score and 
placing the data in the cache (over previously learned data).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

---

From: Mike StJohns <[email-masked]>
Date: Mon, 27 Nov 2006 11:39:31 -0500

>placing the data in the cache (over previously learned data).

Agreed.

---

From: Mike StJohns <[email-masked]>
Date: Tue, 28 Nov 2006 14:20:29 -0500

At 08:21 AM 11/27/2006, Scott Rose wrote:
>Mike StJohns wrote:
><snip>
>>The counter argument to doing this is that the intermediate 
>>validator doesn't have enough information to make a good policy 
>>decision on what to do in this situation.  The validator would need 
>>additional information about why the DNS question was being asked 
>>to do the "right" thing. E.g. blocking the data for an HTTP 
>>connection might be the right idea, but blocking it for HTTPS is 
>>probably the wrong idea because the underlying TLS connection has a 
>>better validation scheme.
>Sometimes this is true, and sometimes it isn't.  In some 
>organizations, a centralized policy at the caching resolver is 
>easier to implement than upgrading all the stubs.  Since all of the 
>stubs will be following the same policy, it is easier to deploy and 
>manage at the recursive server than the stubs.

Agreed that it is easier to do central management, but this is like 
the old joke:

A guy is walking along the street and comes across another guy down 
on his hands and knees under a streetlight.  The walker watches for a 
moment and asks - "what are you doing?"  The guy on his knees replies 
- "I dropped a diamond ring and I'm trying to find it."  So the 
walker says "let me help", gets down on his own knees and proceeds to 
look for the ring too.  After about 15 minutes, the walker says "I 
can't find it - where exactly did you drop it?".  The other guy 
points to a location about 10 feet away and says "over there" - "Why 
are you looking here?" "Because the light better!"
It doesn't matter if you *can* do central management, if the results 
from doing it are bad - e.g. you're enforcing policy in the wrong 
location simply because it's easier.

One of the other emails on this thread suggest that "bogus" would 
most often result from an attack. I think that's probably a weak 
assumption.  I don't know how to characterize this as we have no 
data, but I'd be willing to bet that at least for the first few 
years, the bogus result will most (>>>) often come from bad 
administration (missing rrsigs, wrong set of rrs in an rrset so bad 
summary, absent DS, present DS but no associated DNSKEY in the tree, 
etc) as opposed to attacks.

[One way to gain some insight here might be to compare a number of 
zones delegated from .COM - specifically, look at the set of NS and 
glue A records at the parent and compare them to the set of NS 
records at the child along with the real A records - while this is 
not completely predictive, it might give some good ideas of the rate 
of administrative errors between parent and child]

So given the unsettled question of whether or not bogus will tend to 
be from real attacks or from mis-configurations, and given that 
certain applications (HTTPS, SIP, SSH, etc) have their own non-DNS 
validation approaches, does the benefit from preventing "really 
bogus" data from reaching a naive client for all queries outweigh the 
problems that come from preventing "administratively bogus" data from 
getting through?

>However, for roaming and solo DNS clients (whose upstream cache does 
>not belong to the same administrative entity), it makes sense to 
>have the end user do its own validation.  And eventually, validation 
>would be pushed down to all end users as upgrades are performed.

Yup.

>>"synthesized answers bad" side of the argument when discussing 
>>things like "Sitefinder".  Is there a meaningful way to 
>>differentiate that general concept of answer synthesis from DNSSECs concept?
>>If there isn't, does the concept of intermediate validation 
>>continue to be reasonable for any version of DNSSEC?
>
>For some, it is reasonable to view intermediate validation as a 
>stepping stone along the deployment path.
>
>Scott
>
>>Mike
>>Mike
>>-- to unsubscribe send a message to [email-masked] with

---

From: Robert Story <[email-masked]>
Date: Tue, 28 Nov 2006 16:30:39 -0500

On Sun, 26 Nov 2006 20:41:57 -0500 Mike wrote:
MS> The counter argument to doing this is that the intermediate validator 
MS> doesn't have enough information to make a good policy decision on 
MS> what to do in this situation.  The validator would need additional 
MS> information about why the DNS question was being asked to do the 
MS> "right" thing. E.g. blocking the data for an HTTP connection might be 
MS> the right idea, but blocking it for HTTPS is probably the wrong idea 
MS> because the underlying TLS connection has a better validation scheme.

I think you are right that the validator doesn't have enough
information to make a good policy decision for all cases. But I think
'better safe than sorry' is a good default. Applications that think
they can do better already have a mechanism for doing so - setting the
CD bit.

MS> In general, the IETF and others have come down on the side of 
MS> "synthesized answers bad" side of the argument when discussing things 
MS> like "Sitefinder". Is there a meaningful way to differentiate that 
MS> general concept of answer synthesis from DNSSECs concept?

Sitefinder is a horse of a completely different color. Redirecting a
user to somewhere they didn't ask for is nothing like redirecting a
user away from somewhere that might not be what they think it is. It's
deception vs protection.

-- 
Robert Story
SPARTA

---

From: Mike StJohns <[email-masked]>
Date: Thu, 30 Nov 2006 13:47:50 -0500

>they can do better already have a mechanism for doing so - setting the

Right... and an SO validator will do that.  You and I think PHB talk 
about "better safe than sorry" (he used "conservative").  The 
question here is what's more conservative and keeping with general 
robustness principles?  Blocking data because you're weren't able to 
validate it (which can be different from the data was actually an 
attack), or passing it through with some indication it might be bad 
and letting the end application decide? I'd argue the latter would 
have been the correct approach, but would have required changes to 
the applications and hence was not the path taken.

DNSSEC PNE with intermediate validation has the principle that a 
single administrative error (e.g. signing the root dnskey rrset with 
an unknown trust anchor, fat fingering the DS summary of a delegation 
point) can cause an entire part of the DNS tree to disappear from 
non-validating end-application view.  This scares me... a lot.

>user away from somewhere that might not be what they think it is. It's

An intermediate validating resolver synthesizes an answer that says 
that data at your query point doesn't exist, regardless of whether it 
the resolver saw something in response.  Sitefinder synthesized an 
answer that said that data at your query point did exist (and 
although Sitefinder did it at the origin, there are plenty of 
resolvers that can intercept a NXDOMAIN answer and synthesize a 
replacement local to the user).  In both cases, the user is being 
lied to - and both arguments are "its for his own good"

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Dec 2006 09:47:01 +1100

> the resolver saw something in response.

	No.  It says: I was not able to get a valid answer as to
	whether the data exists or not (SERVFAIL).  This is different
	to staying that the answer does not exist (NXDOMAIN/NODATA).

	getaddrinfo() returns a different error codes.  EAI_AGAIN
	vs EAI_NONAME or EAI_NODATA.

	A naive application may treat them the same by many
	applications don't.

>  Sitefinder synthesized an

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Dec 2006 12:35:08 +1100

> non-validating end-application view.  This scares me... a lot.
 
	There are lots of ways whole branches can disappear in the
	DNS today.  DNSSEC just adds a few more.

	I have on a number of occasions said that registries today
	should at delegation time and periodically there after check
	delegations and get the broken ones fixed.  e.g. ensure
	that NS RRsets match, ensure that glue address records
	match, etc.

	I keep getting told "this is not the registry's job" or "we
	can't to this as we have registrars" or "we can't do this
	at delegation time because we have to perform the delegation
	within X seconds", etc.

	The DNSSEC errors above fall into the same class of error.
	I just need someone to decide to take responability for
	what they are doing and *manage* what is happening and not
	race for the almighty buck.

	Mark

	P.S.  I also think that failure to fix delegations in a
	timely maner should result in the delegation being pulled.
	This is nothing new. There is already a RFC which states
	that errors in the child should be reported to the parent
	if the child fails to respond with the ultimate penalty
	being that the delegation is pulled.

---

From: Rob Austein <[email-masked]>
Date: Thu, 30 Nov 2006 21:01:18 -0500

Intermediate validation is a really bad idea.  It's just better than
not doing validation at all.

There's this little problem of the installed base of DNSSEC-oblivious
stub resolvers.  Intermediate validation is the only way I can see to
protect them.  I'd strongly prefer that all stub resolvers eventually
turn into validating stub resolvers, but that'll take a while.