Subject: draft-ietf-dnsext-dnssec-opt-in-07.txt

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Aug 2005 10:42:03 -0400

Referencing: 
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-07.txt

I would have to say that once again I bristle with special case rules like
"only delegations" can be in unsigned spans.  Before I say it is ultimately
justified and needed, the reason I bristle is the brush up with DNAME.

However, I don't think the problems with * DNAMEs in caches apply to this.

# 4.1.3  Wildcards and Opt-In
#
#    The intent of the standard DNSSEC negative wildcard proof requirement
#    is to prevent malicious users from undetectably removing valid
#    wildcard responses.  In order for this cryptographic proof to work,
#    the resolver must be able to prove:
#
#    1.  The exact qname does not exist.  This is done by the "normal"
#        NSEC record.
#    2.  No applicable wildcard exists.  This is done by returning a NSEC
#        record proving that the wildcard does not exist (this is the
#        negative wildcard proof).
#
#    However, if the NSEC record covering the exact qname is an Opt-In
#    NSEC record, the resolver will not be able to prove the first part of
#    this equation, as the qname might exist as an insecure delegation.
#    Thus, since the total proof cannot be completed, the negative
#    wildcard proof NSEC record is not useful.
#

I think that some of this section can be cleaned or tightened up by
saying that if a closest encloser is unsigned, then it must be a delegation
point.  Hence, a unsigned RRSet can not be the reason for failing to
synthesize from a (signed) wildcard.  I.e., you don't have the (RFC 1034)
section 4.3.2, step 3, part c to worry about here because you'd be in part b.

On another point, denying the existence of a name in an unsigned span
ought to follow the rules for denying existence without DNSSEC (ie, no
denial of wildcards), denying the existence of a name in a signed span
does follow the DNSSEC rules (ie, including the wildcard denial).

# 4.2.1  Delegations Only
#
#    As stated in the "Server Considerations" section above, this
#    specification restricts the namespace covered by Opt-In tagged NSEC
#    records to insecure delegations only.  Thus, resolvers MUST reject as
#    invalid any records that fall within an Opt-In NSEC record's span
#    that are not NS records or corresponding glue records.

Does this mean that an API reacts as if rcode=SERVFAIL is returned?

# 4.2.3  NSEC Record Caching
#
#    Caching resolvers MUST be able to retrieve the appropriate covering
#    Opt-In NSEC record when returning referrals that need them.  This
#    requirement differs from standard DNSSEC in that the covering NSEC
#    will not have the same owner name as the delegation.  Some
#    implementations may have to use new methods for finding these NSEC
#    records.

This ought to reference NCACHE (2308?).  I don't think we want to make
caches search for records (internall), rather that caches keep negative
answers cached separately from positive answers.

# 8.  Security Considerations

I think the object here is to answer the question:

   Can any RRSet (signed or unsigned) cause ambiguity over the security
   of another signed RRSet in the same zone?

# Appendix A.  Implementing Opt-In using "Views"

Considering "Views" are not defined anywhere, this could be a landmine of
a section.
Edward-Lewis-Computer:~ edlewis$
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

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