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

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