Subject: "orphaned" RRsets & DNSSEC

From: [email-masked]
Date: Mon, 21 Nov 2005 18:32:42 +0000

So... Hokay...

	DNSSEC is a fine and useful BOS ... but there is this little nagging
problem that is bugging me.  One of the lemas is that zones are signed, which 
leaves the small problem of validating glue.  others have argued that the
proper response is to insist on all glue be removed by excising all the 
"out of baliwick" data - forcing servers to being the zone.  nice idea, but
will take a -LONG- time to gain operational traction.  So in the mean time,
we have signed zones w/ "orphaned" RRsets.

	Is there any reason why we can't validate the NS records, perhaps 
using the same general techniques as would be used for incremental signing?

--bill

--
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: Mon, 21 Nov 2005 13:47:35 -0500

>using the same general techniques as would be used for incremental signing?

I'm not clear on the question.  Are you asking why the parent doesn't 
sign the cutpoint NS RRset?  Are you calling the NS RRSets part of 
the glue?  (I've always thought the glue to be the address records 
pertaining to the cutpoints and not the NS sets.)

One of the basic tenets of DNSSEC is to have the authority on a RRset 
be the sole provider of authentication meta-data, i.e., the signature.

I've always liked the model of "let the NXT record note the presence 
of an NS set and have that signed" as proof that a cut point was 
granted by the parent without making a statement about the "Left Hand 
Side" of the NS data.  Only the child signs the NS RRsets, the 
appropriate authority signs the address records that appear as glue.

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

3 months to the next trip.  I guess it's finally time to settle down and
find a grocery store.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Nov 2005 19:05:58 +0000

# 	DNSSEC is a fine and useful BOS ... but there is this little nagging
# problem that is bugging me.  One of the lemas is that zones are signed,
# which leaves the small problem of validating glue.  others have argued that
# the proper response is to insist on all glue be removed by excising all the
# "out of baliwick" data - forcing servers to being the zone.  nice idea, but
# will take a -LONG- time to gain operational traction.  So in the mean time,
# we have signed zones w/ "orphaned" RRsets.

dnssec only signs authority data.  glue is (by definition) not authority data.

the way glue is protected is that if you follow a delegation using supplied
glue and the server you reach isn't signing its data with the key the parent's
DS gave you, you know that the glue is evil and you can discard it, signal an
error, try the next glue, refetch the glue from the apparent real nameservers
for the enclosing zones of the glue, or treat the zone as "in failure",
according to (drum roll, please) "local policy".

this leads directly to the problem masataka pointed out ten years ago, where
if all of FOO.NET's nameservers are under FOO.COM, and vice versa, there's a
reasonable chance of both zones becoming unreachable.  DNSSEC does not create
that problem, it's inherited from DNS.  DNSSEC doesn't even make it any worse.

# 	Is there any reason why we can't validate the NS records, perhaps
# using the same general techniques as would be used for incremental signing?

yes.  because we have to stop adding requirements some day.  let's start now?

---

From: [email-masked]
Date: Mon, 21 Nov 2005 20:15:10 +0000

> pertaining to the cutpoints and not the NS sets.)

	the NS RRset and the associated PTR records ...

> be the sole provider of authentication meta-data, i.e., the signature.

	yes.

> appropriate authority signs the address records that appear as glue.

	that gets me partly where i want to go... :)

---

From: [email-masked]
Date: Mon, 21 Nov 2005 20:13:06 +0000

> dnssec only signs authority data.  glue is (by definition) not authority data.

	not authority data for the zone in question.  it is authority
	data for some part of the heirarchy tho...

> according to (drum roll, please) "local policy".

	yes, yes...  the presumption of fully signed heirarchy and/or locally
	maintained TA's...  Is that -ALL- there is for choice?

> that problem, it's inherited from DNS.  DNSSEC doesn't even make it any worse.

	well, DNSSEC doesn't make it better.  and in the presence of actual
	application validation attempts, it couldbe much worse.

> yes.  because we have to stop adding requirements some day.  let's start now?

	er... because we have to stop is not, IMHO, a credible reason.

	or are you sugestting that this is such a fundamental change, that
	we would have to scrap what has been done to add/integrate this	
	spiffy chromed hood ornement to the DNSSEC funny car?
	
	or, are you concerned that DNSSEC will never gain adoption as long
	as there are suggested changed, modifications, additions, tweeks,
	etc. being proposed?  Kind of like the DNS will never gain adoption
	until people stop trying to add, change, modify or tweek it?

--bill

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Nov 2005 20:42:07 +0000

# > dnssec only signs authority data.  glue is (by definition) not authority
# > data.
# 
# 	not authority data for the zone in question.  it is authority
# 	data for some part of the heirarchy tho...

in principle, then, a referring server could fetch, validate, and transmit
the covering RRSIGs for any out-of-bailiwick glue it wants to hand out?

# > according to (drum roll, please) "local policy".
# 
# 	yes, yes...  the presumption of fully signed heirarchy and/or locally
# 	maintained TA's...  Is that -ALL- there is for choice?

the decision was made about a decade ago to force trust to follow delegation.
while it'd be a nicer security market if anybody could sign anybody else's key,
that's not what we ended up deciding.

# > because we have to stop adding requirements some day.  let's start now?
# 
# 	er... because we have to stop is not, IMHO, a credible reason.

if you think endless design and redesign and requirement change is credible,
then i want some of whatever funding YOU'RE smoking.  (mine isn't like that.)

# 	or are you sugestting that this is such a fundamental change, that
# 	we would have to scrap what has been done to add/integrate this	
# 	spiffy chromed hood ornement to the DNSSEC funny car?
# 
# 	or, are you concerned that DNSSEC will never gain adoption as long
# 	as there are suggested changed, modifications, additions, tweeks,
# 	etc. being proposed?  Kind of like the DNS will never gain adoption
# 	until people stop trying to add, change, modify or tweek it?

i'm suggesting that we have to call it deployable, and deploy it, and then we
can go right on changing it.  just like was done with dns, which was a total
trainwreck when deployed, by today's lofty standards.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 22 Nov 2005 06:12:16 +0900

> the covering RRSIGs for any out-of-bailiwick glue it wants to hand out?

The solution, as I said 10(?) years ago, is to add tags to
glues in cache.

Glues in cache should be tagged with parent zones of the referral
points (though it is better to tag with referred zones, it involves
modification to zone file format, XFER protocols etc.).

The cached glues should not be used to answer normal reply.

Cached glues should be used for cached referral if tags match
the referring zones.

There is nothing DNSSEC specific.

						Masataka Ohta

---

From: [email-masked]
Date: Mon, 21 Nov 2005 21:15:30 +0000

> the covering RRSIGs for any out-of-bailiwick glue it wants to hand out?

	if such out-of-baliwick glue was in part of a signed heirarchy itself
	-AND- the local system attempting the validation had associated Trust Anchors
	for those parts of the signed heirarchy...

> that's not what we ended up deciding.

	so for the dnssec trust model, self-signed or third-party signatures are
	not to be used/trusted.  but does this lema preclude the existance of 
	such signatures?

> then i want some of whatever funding YOU'RE smoking.  (mine isn't like that.)

	dns (and dnssec) have been inthe process of "endless design and redesign" 
	since their inception.  i'm not asking for anything more than status quo.
	if you -WANT- the kind of funding that supports and encourages research
	(where its ok to have novel ideas that may not fly in the commercial world)
	then that kind of funding is there... but there are downsides... as is 
	true w/ nearly all funding models.

> trainwreck when deployed, by today's lofty standards.

	dns was never frozen while it was being deployed.  and i suspect dnssec 
	won't be either.  

--bill

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Nov 2005 16:54:55 -0500

Since we can't have a good argument unless we know we are arguing about:

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
GLUE RECORDS

    If the name server host for a particular domain is itself inside the
    domain, then a 'glue' record will be needed.  A glue record is an A
    (address) RR that specifies the address of the server.  Glue records
    are only needed in the server delegating the domain, not in the
    domain itself.  If for example the name server for domain SRI.COM was
    KL.SRI.COM, then the NS record would look like this, but you will
    also need to have the following A record.

Also, RFC 1034, 4.2.1

    to learn.  To fix this problem, a zone contains "glue" RRs which are not
    part of the authoritative data, and are address RRs for the servers.

And so on.  Glue records are address records, not NS records, not PTR 
records.  Maybe you want to change design assumptions after the cows 
have come home to roost, but don't go changing terminology - it just 
annoys the pigs.

At 21:15 +0000 11/21/05, [email-masked] wrote:

>	not to be used/trusted.  but does this lemma preclude the existance of
>	such signatures?

We really tried to make a general purpose trust model work.  We 
really, really tried hard.  There was even a US DARPA research task 
to study this called FMESHD.  The fact is that no one has been able 
to find an approach that isn't an open door to a denial of service 
attack.  Maybe there is one, but no one has found it.

In a nutshell, having one key signed by another, and then vice versa 
is a nice little infinite verification loop.  'Course, we could treat 
loops like CNAME does.  But an implementation would have to also put 
an arbitrary cap on chasing extended signature chains.

It's a mess, yes, and it was pushed aside as a neat little idea that 
was operationally not feasible.  You should have seen the early 
cartoons and diagrams of "up tree validation" and the others.  I 
remember trying to demonstrate it with a bag of paper clips, showing 
how it made the root of the DNS tree just another arbitrary starting 
point.  (Too bad we didn't document those goofy ideas, huh?)

I would say that the presence of third party signatures (I used to 
call them non-germane signatures) is a problem for naive code bases 
that may try to track them down into a dark alley.

>	dns was never frozen while it was being deployed.  and i suspect dnssec

I don't think that is a safe assumption.  DNS was deployed in an era 
of no oversight.  The Internet didn't matter to anyone outside the 
club of engineers that worked on it.  Now that the Internet matters 
to daily life (I would stop short of saying it is essential) DNS and 
DNSSEC will seem frozen or glacial.  Note the speed with which the 
root zone has taken up DNSSEC.  Policy dudes don't like shifting 
sands, they will put in concrete barriers to stop "erosion."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Nov 2005 23:03:52 +0000

# 	dns was never frozen while it was being deployed.  and i suspect
# 	dnssec won't be either.

at some point dns stopped invalidating its installed base, as dnssec must do.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Nov 2005 10:17:13 +1100

I was talking about this in the halls at Vancouver.

	My idea was to have a GLUESIG to cover delegating NS and
	address records.  This would cover the gap we currently
	have in that not all data entered into a signed zone can
	be cryptographically verified when it is received.

	This would prevent resolvers being lead astray by being
	given forged NS / A / AAAA RRsets.  The model would be
	verify before following rather than follow and hope that
	you get something that can be validated.

	Not having this is not a show stopper, but it is something
	we should work on fixing.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Nov 2005 11:37:46 +1100

> we have signed zones w/ "orphaned" RRsets.

	Removing "out of baliwick" data will actually increase the amount
	of glue required not remove it.

	One could constuct a DNS such that there was no glue other than
	the SBELT needed to get to the roots.  The servers for the TLD
	would live in a undelegated part of the root zone.  The servers
	for the childen of a TLD would live in a undelegated part of the
	TLD zone.  etc.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Nov 2005 12:01:49 +1100

> be the sole provider of authentication meta-data, i.e., the signature.

	Early on in the development of DNSSEC we made a decision
	not to sign the glue and delegation records.  We could do
	this because signing them was not strictly needed to prevent
	bogus data being returned from a signed child zone.  

	If I was asked to make the same decision today in the
	presence of wide spead DoS attacks and spoofed traffic I
	have made choice to protect the resolver from going down
	the rathole, i.e. sign the delegation and glue.

	The attackers have got better so the defences need to be
	better.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Nov 2005 21:43:44 -0500

I have a hard time seeing this as needed.

Assuming the parent and child are signed, a referral from the parent 
to the child would have a signed DS set, an unsigned NS set, and 
unsigned glue records.   Assuming the glue is faked, the DS set 
provides the protection as no key is found matching any DS record.

Signing the glue doesn't make it harder to substitute it.

All I can see you'd save in verifying glue before following a 
referral is a query to a server that won't give you verifiable data. 
You lose time, not much more.  However, if you do verify all 
referrals, you lose the same or less time more often.

It's possible that I am missing the point, but I don't see how 
signing the glue helps.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Nov 2005 14:23:57 +1100

> It's possible that I am missing the point, but I don't see how 

	I prevents the resolver following a bogus referrals in the
	first place.  It allows resolvers to free resources sooner
	rather than later.

	While it is impossible to survive a MiM attacks it is possible
	to survive injected response attacks by waiting for later
	responses from the real servers.  The sooner one can do this
	the less resources that need to be tied up to allow for
	recovery from the attack.

	Note a cleverly defined attack could have a valid DS/DNSKEY
	chain but everything else could be invalid.

	Mark

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Nov 2005 22:42:38 -0500

At 14:23 +1100 11/22/05, Mark Andrews wrote:

>	It prevents the resolver following a bogus referrals in the

It only helps if you do the crypto operations as you go?  Every 
referral?  If so, here's why I have a hard time being convinced that 
it is worth the effort.

Assuming the number of queries that get attacked is 1% (probably 
high), then 100% of the time you are eating resources to find the 1% 
of the times you sense an attack.  When you sense an attack, you save 
one round of queries by not sending anything to the duping servers. 
Is the 100% of query overhead worth the savings?

>	recovery from the attack.

It is always true that the sooner you can free resources used for 
fruitless work, the better.  The trouble is, as always, determining 
when an effort is fruitless.  (That's like having "perfect future 
knowledge" when playing a game.)

>	chain but everything else could be invalid.

For some value of "cleverly defined" of course.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Nov 2005 14:56:19 +1100

> It only helps if you do the crypto operations as you go?

	Yes.

> Every referral?

	Every referral from a secure zone.  Just in time for the
	addresses.  It also helps provide some additional assurance
	when going from a secure zone to a unsecure zone.

> If so, here's why I have a hard time being convinced that it is worth 
> the effort.
> 

	You save many queries when under attack.

	Mark

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Nov 2005 04:10:54 +0000

# 	You save many queries when under attack.

i believe that ken orr's work demonstrates conclusively that if there are
parallel databases, at least one of them will be wrong most of the time.