Re: comments on draft-ietf-dnsext-dnssec-bis-updates-04.txt

[Sam Weiler <[e-mail]>]

> # 2.1.  Clarifications on Non-Existence Proofs
> #
> #    [RFC4035] Section 5.4 slightly underspecifies the algorithm for
> #    checking non-existence proofs.  In particular, the algorithm there
> #    might incorrectly allow the NSEC from the parent side of a zone cut
> #    to prove the non-existence of either other RRs at that name in the
> #    child zone or other names in the child zone.  It might also allow a
> #    NSEC at the same name as a DNAME to prove the non-existence of names
> #    beneath that DNAME.
> 
> The above paragragh is unclear.  A "NSEC" does not prove anything, proofs are
> done by the validotor.  An NSEC RR and its associated RRSIG present data
> used in a proof.

This usage is consistent with RFC4035 (e.g., "... a single NSEC RR may prove 
both of these points.")  Is this so bad that we need a new section talking 
about the use of the verb "prove" in 4035?

> The "either" probably ought to be stricken from "of
> either other" in the middle.

Done.

> "It might" - does it or not?

It depends on the clue of the person reading it?  Is there really a 
problem with that wording?

> This sounds like an augmentation of the specified proof, you have a lower
> case MUST in there.  (Also, s/singer/signer/.)  On the last line,
> s/descendant/subdomain/.

Fixed.  Thank you.

> # 2.2.  Empty Non-Terminal Proofs

Removed at Roy's suggestion.

> # 2.3.  Validating Responses to an ANY Query
> #
> #    (as clarified in this document).  To be clear, a validator must not
> #    insist on receiving all records at the QNAME in response to QTYPE=*.
> 
> s/insist/expect/ perhaps.

Done.

> # 3.  Interoperability Concerns
> #
> # 3.2.  Private Algorithms
...
> It says here that the "resolver MUST retrieve ... and ... determine the
> algorithim."   How can it determine the algotrithm if the algorithm is
> private?  It is possible that multiple algorithms use the same private
> number, the best that can be done is if the private algorithm just happens
> to be one the resolver knows and is expecting.

There is a spec for how to distinguish between private algorithms. See RFC4034 
Section A.1.1.

> There is one step here - instruct the resolver to "line up" individual
> DS RRs and DNSKEY RRs.  This may not be possible if an unknown DS hash
> algorithm is in use.  Of the ones that line up, you can go on with sanity
> checking.

The section acknowledges that the hash algorithm must be known.

> Do you want the resolver to side on being optimisitc?  Should the resolver
> be satisfied if it can find one useable DNSKEY?  Or do you want it to be
> pessimistic and through an exception when it can't line up and verify all
> key records?

Optimistic.  Strictly optimistic.  This comes close to implicating the "safety 
property" that we discussed in early 2003.

> # 3.3.  Caution About Local Policy and Multiple RRSIGs
> #
> #    When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3
> #    suggests that "the local resolver security policy determines whether
> #    the resolver also has to test these RRSIG RRs and how to resolve
> #    conflicts if these RRSIG RRs lead to differing results."  In most
> #    cases, a resolver would be well advised to accept any valid RRSIG as
> #    sufficient.  If the first RRSIG tested fails validation, a resolver
> #    would be well advised to try others, giving a successful validation
> #    result if any can be validated and giving a failure only if all
> #    RRSIGs fail validation.
> 
> The point missed here is that it is possible that a resolver wants to see a 
> record signed with two or more algorithms, reflecting multiple "sign offs" of 
> the record.  I doubt that this is an operational scenario grounded in sanity, 
> but I would not recommend in this clarification what policy a resolver should 
> favor.

Noted.  I'll await more feedback before changing this section.

> #    If a resolver adopts a more restrictive policy, there's a danger that
> #    properly-signed data might unnecessarily fail validation, perhaps
> #    because of cache timing issues.  Furthermore, certain zone management
> #    techniques, like the Double Signature Zone-signing Key Rollover
> #    method described in section 4.2.1.2 of [RFC4641] might not work
> #    reliably.
> 
> What is meant by "more restrictive?"  "There's a danger...might...perhaps" is
> a bit vague.

This section is non-committal, perhaps, but is it really so unclear as to need 
to be changed?  Again, I'd like more feedback (perhaps with alternative text 
suggested.)

> # 3.6.  Responding to QTYPE=* with the DO Bit Clear
> 
> Already commented on this in email (Wouter and Koch too).

Absent some support for this section (which I thought my co-editor would be 
offering), it's been removed.

> # 4.  Minor Corrections and Clarifications
> #
> # 4.1.  Finding Zone Cuts
> 
> I don't see what 4.1 is addressing.  It seems all of references are
> to parts of the same document.

At this moment, I'm not recalling why it was added either -- most likely, 
someone showed up on namedroppers asking about it and I agreed that the lack of 
a cross-reference in RFC4035 C.8 could plausibly be confusing.  There's a 
reason stuff this minor is in section 4 rather than earlier in the doc...

> # 4.2.  Clarifications on DNSKEY Usage
> #
> #    Questions of the form "can I use a different DNSKEY for signing the
> #    X" have occasionally arisen.
> 
> "Signing the X?"  What does that mean?

Clarified.

> # 4.3.  Errors in Examples
> 
> Earlier this doc said it didn't deal with typos - but that is what this
> section is all about - a typo.
> 
> # 4.4.  Errors in Canonical Form Type Code List
> 
> Is this too just a typo report?

I think these fall into the bucket of "typos ... [that] could lead to 
misinterpretation...".  I removed the "Mere typos..." line from the intro to 
address this.

-- Sam


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