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

From: David Blacka <[email-masked]>
Date: Thu, 18 Aug 2005 12:45:50 -0400

On Aug 18, 2005, at 10:42 AM, Edward Lewis wrote:

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

The intent of this draft was to publish, as experimental, the  
previous work on Opt-In, which ended up being delegation only for  
both practical and, um, moral, reasons.

If there was actual interest (and I doubt there is) we could  
certainly try to cast a non-delegation-only version of opt-in as a  
different experiment.  But I think that it would be a bit of work to  
redo the analysis.

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

I believe you, but you need to show me.  That is, I personally cannot  
see how to turn this comment into tighter text.

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

Does it not already say this, in effect?  Note that this document  
isn't directly addressing what happens in a signed span, as that  
doesn't change from 4035 DNSSEC.

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

This draft (and 4033-4035 for that matter) describe the protocol, not  
the API.  It is attempting to say, in as neutral a way as I could  
think of, that non-delegation records are not allowed.  I always  
imagine that the situation would be treated exactly the same as a  
validation failure, but how the API actually handles this is up to  
the API.

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

This section is talking about returning cached referrals, not  
negative answers.  Are you saying that it should talk about returning  
negative answers as well?

Note the "advice" was intentionally quite vague as to what caches  
actually need to do differently.  This was all based on the point  
that normally a cache has a very easy way to find the NSEC that  
accompanies a referral to an unsigned subzone: it just looks for NSEC  
records named the same as NS rrset.  Opt-In makes this not work.

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

I thought the purpose of this section was to accurately describe how  
opt-in changes the security of your zone when compared to 4035.   
Which I thought it did.  And I also thought that it answered your  
question.

> # Appendix A.  Implementing Opt-In using "Views"
>
> Considering "Views" are not defined anywhere, this could be a  
> landmine of
> a section.

Heh, that is why the term is quoted.  And I thought the section  
actually defined what it meant by the term, albeit briefly.  Maybe  
not well enough.

--
David Blacka    <[email-masked]>
Sr. 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.
archive: <http://ops.ietf.org/lists/namedroppers/>