Protection of unsecured delegations

[Ólafur Guðmundsson <ogud@ogud.com>]

The strongest argument I have heard against OPT-in is that
"OPT-in removes the protection of the innocent get with DNSSEC".
All other arguments fall into,
	"not convinced we need this",
	"this is ugly and/or complicated",
	"Verisign must have ulterior motive, therefor this is bad".

After thinking about what Roy Arends said in the DNSEXT meeting in
the OPT-in presentation, I think we need to reassess the "harm" done
by OPT-in.


Attacks against Delegations
	a. Denial of existence
	b. Diversion of DNS queries via forged NS set (forged reply)
		b.1 delegation looks lame.
		b.2 Lying about the contents of a delegated zone

A. Denial of existence in DNS is done by
RFC1035  Rcode=NXdomain, an=0, au=1, authority section contains SOA
RFC2535  same as above and NXT record is added to authority section.
DS       same as RFC2535
OPT-in   same as RFC2535

B. Diversion of DNS queries is done by sending back different NS set.
Remember NS in parent is not signed.

RFC1035 resolver with properly implemented random Query ID and random
port make these attacks hard or limit them to an attacker that sees
the query stream, but all are possible.

RFC2535, or DS or OPT-in in parent does not help RFC1035 resolver
thus provides no protection against any of the attacks.

RFC2535 in parent prevents RFC2535 resolver from believing case a. BUT
the if the NXDomain answer arrives before the real answers, it may prevent
the resolver from accepting the real one thus accomplishing the
same result. This only applies to nameservers/resolvers that only
listen to the first message returned in response to a query.
RFC2535 resolver is still vulnerable to b.1 and b.2 because the
NS set is unsigned.

DS zone
DS capable Resolver has same vulnerabilities as RFC2535 one.
RFC2535 capable resolver might be susceptible to a., in this case
when it performs a check on the NXT record and seeing unknown bit (NODS)
rejects the NXT even though the signature verifies the contents.

OPT-in zone
OPT-in capable resolver is vulnerable to all attacks at unsecured
delegations.
IF the covering NXT is played back against RFC2535-only capable
resolver, it will return that the delegations provably does not exist.
OPT-in resolver has same vulnerabilities as RFC2535 one at secure
delegations.

In short, signing delegation zone like .com the only protection that
unsecured delegations get at security aware resolvers, is against the
crudest attack, no protection is offered against the others.
All secure delegations are still vulnerable to B.1,
Accomplishing B.2 is real hard without key compromise.

Given all above
Question: Is Opt-in "mostly harmless" ?

If answer is yes, what rules do we set for OPT-in.
	1. Only allowed in delegation zones (like .com)
	2. Only skip unsecured delegations but protect other names
	3. Skip any name in a zone other than apex.

1. is the case used to motivate and justify
2. is where DNSSEC provides least protection.
3. Is the general case and addresses the NXT walk concerns that some
    operators and policy people bring up time again and again.

	Olafur



to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.