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

[Edward Lewis <[e-mail]>]

>  Title: Clarifications and Implementation Notes for DNSSECbis
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-04.txt

This is not on the agenda for San Diego?

#          Clarifications and Implementation Notes for DNSSECbis
#                 draft-ietf-dnsext-dnssec-bis-updates-04
#
# Abstract
#
#    This document is a collection of minor technical clarifications to
#    the DNSSECbis document set.  It is meant to serve as a resource to
#    implementors as well as an interim repository of DNSSECbis errata.

 From reading further in the document, there is more here than just
clarifications, there are augmentations and changes to the protocol.

# 1.1.  Structure of this Document
#
#    The clarifications to DNSSECbis are sorted according to the editors'
#    impression of their importance, starting with ones which could, if

This being a WG document, it really should be a reflection of the WG's
consensus.  In that vein, this document ought to be regularly discussed
on the mailing list and take precedence in the agenda at in person meetings.

#    Mere typos and awkward phrasings are not addressed unless they could
#    lead to misinterpretation of the DNSSECbis documents.

If these are not what is addressed, then this is more than a clarification.

# 2.  Significant Concerns
#
#    This section provides clarifications that, if overlooked, could lead
#    to security issues or major interoperability problems.
#
# 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.  The "either" probably ought to be stricken from "of
either other" in the middle.  "It might" - does it or not?

#    A parent-side delegation NSEC (one with the NS bit set, but no SOA
#    bit set, and with a singer field that's shorter than the owner name)
#    must not be used to assume non-existence of any RRs below that zone
#    cut (both RRs at that ownername and at ownernames with more leading
#    labels, no matter their content).  Similarly, an NSEC with the DNAME
#    bit set must not be used to assume the non-existence of any
#    descendant of that NSEC's owner name.

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

# 2.2.  Empty Non-Terminal Proofs
#
#    To be written, based on Roy Arends' May 11th message to namedroppers.
#
#    The editors are trying to figure out whether what's really required
#    here is a discussion of the relationship between DNS RCODEs and
#    DNSSECbis.

This description makes it sound more like a search for a problem than just
a repository for gaps in the original protocol.  There isn't much of a
relationship between the return codes and DNSSEC because the RCODEs exist
in the un-DNSSEC-protected header of a message.  (I recall a discussion
on this walking through Manchester at the RIPE meeting there two years
ago.)  As much as some of us wanted to develop a state machine based on
the return codes for name error and no error to describe negative answers,
we kept running into a brick wall because the return code field is not
covered by DNSSEC.

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

# 3.  Interoperability Concerns
#
# 3.2.  Private Algorithms
#
#    As discussed above, section 5.2 of [RFC4035] requires that validators
#    make decisions about the security status of zones based on the public
#    key algorithms shown in the DS records for those zones.  In the case
#    of private algorithms, as described in [RFC4034] Appendix A.1.1, the
#    eight-bit algorithm field in the DS RR is not conclusive about what
#    algorithm(s) is actually in use.
#
#    If no private algorithms appear in the DS set or if any supported
#    algorithm appears in the DS set, no special processing will be
#    needed.  In the remaining cases, the security status of the zone
#    depends on whether or not the resolver supports any of the private
#    algorithms in use (provided that these DS records use supported hash
#    functions, as discussed in Section 3.1).  In these cases, the
#    resolver MUST retrieve the corresponding DNSKEY for each private
#    algorithm DS record and examine the public key field to determine the
#    algorithm in use.  The security-aware resolver MUST ensure that the
#    hash of the DNSKEY RR's owner name and RDATA matches the digest in
#    the DS RR.  If they do not match, and no other DS establishes that
#    the zone is secure, the referral should be considered BAD data, as
#    discussed in [RFC4035].
#
#    This clarification facilitates the broader use of private algorithms,
#    as suggested by [I-D.ietf-dnsext-dnssec-experiments].

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

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?

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

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

# 3.6.  Responding to QTYPE=* with the DO Bit Clear

Already commented on this in email (Wouter and Koch too).

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

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

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

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                [phone]
NeuStar

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.

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