Subject: proposed sol'n to the '* NS' problem

From: Edward Lewis <[email-masked]>
Date: Wed, 9 Feb 2005 13:49:49 -0500

The problem with signed zones having a "* NS" is that when the record 
set acts as a source of synthesis, it lacks the requisite RRSIG to 
cover it (as would any other record set synthesized in 
1034/4.3.2/3c).  Without this RRSIG, this, albeit non-sense, 
situation is a place where message substitution can go undetected.

Although this vulnerability is superficially a stupid little corner 
case, I am somewhat concerned that, if left untreated, would allow 
cache poisoning by allowing NS RRsets to be presented to a caching 
element.  I am not sure this is possible - I haven't been able to 
construct the situation with existing code.

In the spirit of, "well, there is an ugly fix to this I can imagine," 
I'll present it here.  This isn't necessarily the best fix, nor does 
this mean that this or any fix is needed.  It is presented here for 
discussion.

In dnssecbis-protocol draft (sitting in the RFC Editor Queue since mid-Oct.):

In Section 2.2, change the original text:

#   The NS RRset that appears at the zone apex name MUST be signed, but
#   the NS RRsets that appear at delegation points (that is, the NS
#   RRsets in the parent zone that delegate the name to the child zone's
#   name servers) MUST NOT be signed.  Glue address RRsets associated
#   with delegations MUST NOT be signed.

to something like:

    The NS RRset that appears at the zone apex name MUST be signed, as well
    as any NS RRset that is owned by a wild card domain name MUST be signed, but
    the NS RRsets that appear at delegation points (that is, the NS
    RRsets in the parent zone that delegate the name to the child zone's
    name servers) MUST NOT be signed.  Glue address RRsets associated
    with delegations MUST NOT be signed.

That takes care of the missing RRSIG, but now means that there is a 
spurious RRSIG in places, as well as a potentially confusing 
situation for the validator.

In section 3.1.1, the original text:

#   o  When placing a signed RRset in the Authority section, the name
#      server MUST also place its RRSIG RRs in the Authority section.
#      The RRSIG RRs have a higher priority for inclusion than any other
#      RRsets that may need to be included.  If space does not permit
#      inclusion of these RRSIG RRs, the name server MUST set the TC bit.

changes to this:

    o  When placing a signed RRset in the Authority section, the name
       server MUST also place its RRSIG RRs in the Authority section,
       with the exception of RRSIGs for a referral NS RRSet.  When a
       non-authoritative server adds an NS RRset to the Authority section,
       its RRSIG MUST NOT be inserted.  (Ordinarily, there isn't such an
       RRSIG, only in the case of a wildcard NS RRset will it appear.)
       The RRSIG RRs have a higher priority for inclusion than any other
       RRsets that may need to be included.  If space does not permit
       inclusion of these RRSIG RRs, the name server MUST set the TC bit.

That takes care of the spurious RRSIG, noting that there is already a rule
saying that all records in the Answer Section are signed.

(My edit is perhaps too wordy.)

In section 5.3.1, this takes care of the authorization-to-sign problem.

The original is:

#   o  The RRSIG RR's Signer's Name field MUST be the name of the zone
#      that contains the RRset;

The new rule is:

    o  The RRSIG RR's Signer's Name field MUST be the name of the zone
       that contains the RRset, with one exception.  If the Type Covered
       field of the RRSIG is NS and the RRSIG Labels field indicates that
       this is a synthesized RRset, then the Signer's Name field MUST be
       the name of the zone above the cut point;

That should take care of the problem, well, that is one way to take 
care of the problem.  Yes, it is a wart.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>