Subject: Re: Protection of unsecured delegations

From: Randy Bush <[email-masked]>
Date: Wed, 19 Dec 2001 14:14:24 -0800

> The strongest argument I have heard against OPT-in is that
> "OPT-in removes the protection of the innocent get with DNSSEC".

not exactly.  it has been generally phrased as

    it changes the basic security model of dnssec from a secure signed
    zone to a collection of signed and unsigned rrsets, and we do not
    _fully_ understand the implications of this from the security pov,
    but some security folk have expressed serious concern.

your message does explore some of the implications.  but i hope smb and
others will express their concerns so that i can understand them.

randy

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 19 Dec 2001 17:07:03 -0500

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

---

From: Roy Arends <[email-masked]>
Date: Thu, 20 Dec 2001 14:49:03 +0100 (CET)

> others will express their concerns so that i can understand them.

There was some consensus after that presentation in that the security
considerations should be stated in a document that is either included or
referred to by the opt-in draft.

I hereby invite security folk to express their serious concern so we can
sieve the FUD and state the residue in either a separate document or
include it in the draft, so we can _fully_ understand the implications of
this from the security point of view.

Oh, btw, I'll volunteer to author that document.

...

Prereq: Please read draft-dnsext-dnssec-opt-in-01.txt

Now, to state in one phrase what opt-in gives up wrt 2535:

    Opt-in gives up authenticated [denial of] existence for unsecured
    delegations.

How is that accomplished ?

    By changing the semantics of the NXT record.

    - 2535 NXT:  Nothing between owner and next domain name exists.
                 (authenticated [denial of] existence).

    - opt-in NXT:Nothing between owner and next domain name is signed.
                 (authenticated [denial of] signatures).

    Note that the latter is a subset of the former. (if a name does not
    exist, a signature for that name does not exist).

    To signal opt-in, the NXT bit is set to zero in the NXT RDATA's
    type-bit-map.

***
How does this change the security context/status/realm ?
***

What follows is a breakdown in 3 parts. The first part discusses the
various active attack types. The second part discusses backward
compatibility issues that introduces security issues. The last part
discusses the possibility to restrict opt-in to unsecured delegations
only.

A) Various Attack types.

   From the secure resolver point of view, there are 3 possible
   attack-types wrt authenticated [denial of] signatures.

   A malicious entity can:

   1) falsely state unsecured delegation information.
   2) falsely state non-existence of unsecured delegation.
   3) falsely state existence of unsecured delegation.

   The first attack-type exist in both the 2535 and the opt-in context.
   The second and third attack-type exist solely in the opt-in context.
   (see [*] below for discussions of the defense against the second and
   third attack type).

   Here follows examples of the three attack-types:

   1) Assume:
         The resolver is opt-in aware.
         A zone (.tld) is signed using opt-in.
         A zone has 2 secured delegations (aaa.tld, zzz.tld)
         A zone has an unsecured delegation (unsecured.tld NS somewhere).

         The resolver wants to resolve "unsecured.tld".

      Attack:
         A malicious entity wants to divert the delegation.

      Method:
         Inject A records for "somewhere" or,
         Change the NS RRSet from "somewhere" to "somewhere_else"

   2) Assume:
         The resolver is opt-in aware.
         A zone (.tld) is signed using opt-in.
         A zone has 2 secured delegations (aaa.tld, zzz.tld)
         A zone has an unsecured delegation (unsecured.tld NS somewhere).

         The resolver wants to resolve "unsecured.tld".

      Attack:
         A malicious entity wants to DoS the delegation by stating
         NXDOMAIN.

      Method:
         Remove all in ANSWER section, an=0,au=1, change the RCODE from
         NOERROR to NXDOMAIN.

   3) Assume:
         The resolver is opt-in aware.
         A zone (.tld) is signed using opt-in.
         A zone (.tld) has 2 secured delegations (aaa.tld, zzz.tld).
         "unsecured.tld" does not exist.

         The resolver wants to resolve "unsecured.tld".

      Attack:
         A malicious entity wants the resolver to believe "unsecured.tld"
         does exist.

      Method:
         Add "unsecured.tld" to the ANSWER section, an=1,au=1, change
         the RCODE from NXDOMAIN to NOERROR

B) Backwards compatibility with 2535.

   2535 and opt-in can co-exist, though the secure resolver needs to be
   able to differ between the two. A resolver that is solely capable of
   1035/2535 (and no opt-in) will either:

     - treat an opt-in NXT record type as bad (it noticed absence of the
       NXT bit in the type-bit-map, and can't compute)

     - treat an opt-in NXT record type as 2535 NXT record type (it ignores
       the absence of the NXT bit in the type-bit-map)

   The above is definitly unwanted. Comparable with deployment of DS, we
   need a "flag date" event to deploy opt-in. Both (DS and opt-in flag
   dates) should probably be the same date if/when it is decided to adopt
   both.

C) Unsecured Nodes vs Unsecured Delegations.

   In the opt-in draft, no difference was made between Unsecured Nodes &
   Unsecured Delegations. (A node = all RRsets with the same owner name)

   The reason for this is that in general, Unsecured Nodes can be
   accomplished by the use of Unsecured Delegations (regardless whether
   2535 or opt-in is used):

       "delegate the node you do not want to secure".

   I have absolutely no problem in restricting the current opt-in draft to
   "unsecured delegations" instead of the more general "unsecured nodes",
   since one can be accomplished by the other.

-----------

[*]

What follows are MHO's:

There is an obvious defense against attack 2, either sign the delegation,
or use 2535 NXT records (revert to 2535). But this is a decision that
is made by the domain-holder/zone-owner, while this decision affects
the end user.

There is an obvious defense against attack 3, replace the encapsulating
opt-in NXT record with a 2535 NXT record (revert to 2535) denying the
existence of the domain. Again, a decision that is made by the
domain-holder/zone-owner. (note that a malicious entity could simply
register the domain, as it was previously non-existent).

As said, opt-in gives up authenticated [denial of] existence for unscured
delegations. These are delegations that were not secure to begin with. The
only service 2535 offers for unsecured delegations is to authenticate its
existence without specifying where it exists.

Regards,

Roy Arends
Nominum

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 20 Dec 2001 11:02:21 -0500

I'd be less concerned about the delegation vs. leaf data issue for
opt-in as long as folks who haven't yet set up fully secured
delegations can opt for 2535-style null key..

I think there needs to be more text on resolver behavior, and, in
particular, a discussion of resolver search paths.

I can see resolvers doing any of:

[a] Do the lookup and only return trusted data.  Not useful to me
until everyone I care about has opted in..

[b] If there's trusted data anywhere on the path, return the first
trusted answer, otherwise return the first non-trusted answer.

[c] Return the first name along the path for which a query returns
some data.

Version [b] provides much better protection of the innocent than [c].

					- Bill

---

From: Derek Atkins <[email-masked]>
Date: 20 Dec 2001 11:09:03 -0500

Bill,

Have you looked at the Delegation Signer (DS) record specification
and how that would relate to Opt-In?

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Roy Arends <[email-masked]>
Date: Thu, 20 Dec 2001 17:27:58 +0100 (CET)

> Version [b] provides much better protection of the innocent than [c].

A secure resolver knows what to expect. It expects a signed statement.
This statement is unambiguous.

so a secure resolver does:

[a] Does the lookup and starts at some secure [super]-domain (it has to
    have a key preconfigured right ?)

or

[b] Does the lookup and does not care about security (it has no key
    preconfigured for a particular [super]domain).

We're talking about [a] here. The resolver knows if it must expect a
secured domain, since the parent unambiguously states that to the
resolver.

Roy Arends
Nominum