comments on delegation signer

[David Blacka <davidb@research.netsol.com>]

I have a few comments about the Delegation Signer draft
<draft-ietf-dnsext-delegation-signer-02.txt>.

First is a fairly minor issue: the DS draft states that in the textual
representation of a DS record, HEX should be used to display the SHA-1
hash.  However, this is inconsistent with the other DNSSEC RR types.
This forces implementors to create or have access to a base16
conversion library, in addition to a base64 library.  I can see no
particularly compelling reason to use hex here, especially considering
that base64 is sufficient for the other DNSSEC records.

My second comment centers around how resolvers determine the security
status of a child zone under this draft.

Section 2.2 states 

  "If a DS RR set accompanies the NS RR set, the intent is to state
  that the child zone is secured. If an NS RR set exists without a DS
  RR set the intent is to state that the child zone is unsecure."

This presents (I think) a security flaw.

If we posit the existence of a sophisticated "man in the middle"
attacker that can arbitrarily change DNS response packets, then this
attacker can convert a secure delegation to an unsecure, hijacked
destination by removing the DS records and signatures and altering the
unsigned NS records.

This vulnerability does not exist using RFC 2535 semantics.  This
attacker could only convert an unsecure delegation to a secure one (by
removing the NULL KEY), which does him no good.  He cannot convert a
secure delegation to an unsecure one, because that would require the
ability to sign a NULL KEY record.

Instead, a better approach might be to require DS enabled servers to
return either: 
   
   NS RR set + DS RR set + SIG{DS} set (for secure delegations)

   OR 

   NS RR set + NXT + SIG{NXT}.         (for insecure delegations)

The NXT record needs to show the non-existence of a DS (or KEY) RR
set.

Merely receiving NS RRs could either be an error (if we are aware that
the zone is using DS) or could be interpreted as a SIG@child
delegation.

This could eliminate the need for a SEC RR or bit in the KEY record to
indicate use of DS, as there would be no ambiguous cases:

delegation:     sec         unsec
            +---------+---------------+
  SIG@child | NS      | NS, NULL KEY, |
            | only    | SIG{KEY}      |
            +---------+---------------+
        DS  | NS,DS   | NS, NXT       |
            | SIG{DS} | SIG{NXT}      |
            +---------+---------------+

-- 
David Blacka         <davidb@research.netsol.com> 
Sr. Research Engineer   Verisign Applied Research