Subject: comments on delegation signer

From: David Blacka <[email-masked]>
Date: 16 Oct 2001 16:28:35 -0400

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         <[email-masked]> 
Sr. Research Engineer   Verisign Applied Research

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

---

From: Derek Atkins <[email-masked]>
Date: 16 Oct 2001 21:19:12 -0400

> that base64 is sufficient for the other DNSSEC records.

Hex is used in the DS draft because pretty much every other security
protocol uses hex to represent hash values.  As for a base-16
"library", last I checked it was provided in LIBC.  Two particular
functions you should know about: "printf" and "scanf".  If that isn't
sufficient for your tastes, any programmer worth their grain in salt
can write a base16 parser in less that 10 lines of C.

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

I was under the impression that this was implied by the fact that the
parent zone was secured in the first place.  The DS SIG on the DS
record is implied by the fact that the parent is secure.  So in the
case of a secure delegation the client should expect NS + DS +
SIG{DS}.  Alternatively is should expect expect NS + NXT + SIG{NXT} in
the case on an insecure delegation.  Again, this is implied by 2535.

> the zone is using DS) or could be interpreted as a SIG@child

Merely receiving NS RRs would violate 2535, so the client would know
something was up.  OTOH, DNSSec does not protect against most DoS
attacks.

-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: Edward Lewis <[email-masked]>
Date: Wed, 17 Oct 2001 16:40:10 -0400

>I was under the impression that this was implied by the fact that the

Either way, the document should make the inclusion of DS or NXT explicit.
Mr. Blacka's assessment that stripping data to go from secure to unsecure
is a concern.  I wonder if that was the thought (that removing data only
makes the source appeared to be more secured[1]) behind the NULL KEY RR set
way back in the day when DNSSEC was first hammered out.

[1] I.e., by removing an insecurity statement, the source appears to be
more secure - hence a signature is expected.  Since zonejackers can more
easily remove records than add seemingly valid signatures, the NULL KEY was
the way to go - up until operational considerations made us question the
workload needed for the approach.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 23 Oct 2001 11:39:55 -0400

>that base64 is sufficient for the other DNSSEC records.

I do not like this change
Reasons:
    As pointed out by Derek all key foot prints use HEX.
    It is simpler to check HEX than base64 (case sensitive) and read it over
         the phone.
    Base64 was opposed by implementors for SIG and KEY records but won
         because of the savings for large records both is size and processing
         time. Contents of KEY and SIG records are not designed for human
         consumption, DS is designed to be human readable.
    Unknown RR also specifies HEX.

>destination by removing the DS records and signatures and altering the

You are right DS as specified has a flaw, in that Secure RFC2535
answer is identical to Unsecure DS answer. This is exploitable as
you say and confuses resolvers.

>ability to sign a NULL KEY record.

A sophisticated attack by a entity that sees all queries from a particular
resolver can convince that resolver that there is NO DNSSEC in use in the
world, thus defeating RFC2535 as well as DS.
DNSSEC protection against "man in the middle" attacks is transaction 
signatures (SIG(0) and TSIG). Any interaction without them is vulnerable
to this attack.

>the zone is using DS) or could be interpreted as a SIG@child

I do not like writing an additional section processing rules that
are dependant if a particular RR set has been added to the additional
section before it. How about changing the current NS set additional section
rule from
         NS + A*
to
         NS  + A* + DS + NXT

In the chase where DS is present the NXT is redundant but harmless.

>indicate use of DS, as there would be no ambiguous cases:

The problem is still that the NXT in the states "sec SIG@child" and
"unsec DS" is identical. A third approach to the two you mention above
is to reserve a bit in the NXT to signal "NO DS at this delegation".
This consumes one type code from DNS but we are only up to 42 so far,
or we can reuse one of the unused type codes that have been allocated but
never used, say SINK (40).

I plan on reissuing the DS draft on Friday with NO-DS bit in NXT,
unless the working group thinks that KEY flag or depend on the
unspecified SEC RR is the way to go.

         Olafur

         Olafur