Re: Protection of unsecured delegations

[Roy Arends <Roy.Arends@nominum.com>]

On Wed, 19 Dec 2001, Randy Bush wrote:

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

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






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