Subject: I-D ACTION:draft-ietf-dnsext-dnssec-bis-updates-04.txt

From: [email-masked]
Date: Thu, 26 Oct 2006 02:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Clarifications and Implementation Notes for DNSSECbis
	Author(s)	: R. Austein, S. Weiler
	Filename	: draft-ietf-dnsext-dnssec-bis-updates-04.txt
	Pages		: 12
	Date		: 2006-10-25
	
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.
   An index sorted by the section of DNSSECbis being clarified.

   A list of proposed protocol changes being made in other documents,
   such as [RFC4470] and [I-D.ietf-dnsext-nsec3].  This document would
   not make those changes, merely provide an index into the documents
   that are making changes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-dnsext-dnssec-bis-updates-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 26 Oct 2006 10:20:52 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-04.txt

In this draft it says:

3.6.  Responding to QTYPE=* with the DO Bit Clear
   To protect resolvers that cannot cope with DNSSEC types, a server
   should not include DNSSEC RR types when responding to a query with
   QTYPE=* and the DO bit not set.

I disagree.
* Resolvers query ANY which means any available and thus could contain
any sort of RR type. Also unknown RR types.
* Resolvers that support unknown RR types (rfc 3597) should have no
problem with unknown (DNSSEC) RR types.
* Is 3.6 to protect resolvers that do not support 3597? To protect those
resolvers not only the DNSSEC RR types, but several more 'recent RR
types' have to be left out, DHCID, SSHFP, maybe APL, DNAME, CERT, KX,
NAPTR, SRV, NXT, LOC, AAAA, PX, KEY too.
I am not sure what needs to be left out, but more than only the DNSSEC
types.

Best regards,
   Wouter

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

---

From: Peter Koch <[email-masked]>
Date: Thu, 26 Oct 2006 12:23:15 +0200

> any sort of RR type. Also unknown RR types.

I fully agree with Wouter and disagree with the recommendation in 3.6.
It is inconsistent and just wrong.

-Peter

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 26 Oct 2006 11:59:32 +0100

> I am not sure what needs to be left out, but more than only the DNSSEC

Fair comment, Wouter.  I'm not sure either.  I think a value judgment
is needed.

It might be useful to step back more than a little, and estimate just
how much bending over backwards is operationally useful to accommodate
or protect "old" resolvers.

Pre-3597 resolvers may treat responses which contain unknown RR types
in a number of ways, of which two extreme cases are easily identified.
In one of these cases, presence of any unknown type would result in
the entire response being treated as invalid and so discarded.  In the
other, a best effort would be made to extract the useful part of the
response.

We can't even hope to measure how actual resolver behaviour is
distributed across the spectrum between these two extremes.  However,
intolerance of "new" RR types and consequent damage would surely have
attracted attention by now if the first case mentioned was the
predominant, or even significantly represented, behaviour.

I suggest that an estimate of the likely "damage" which would result
from a decision to limit backwards compatibility to a "moderate"
degree would be useful.  Put another way, while I appreciate that
accommodating "old" resolvers actually present in the field is  
important,
the effort involved in accommodating putative "really old" resolvers,
whose very existence out there is a matter of conjecture, might not
be justifiable.

Sometimes it's necessary to cross the road, even though the risk of
being hit by a bus is never zero.

/Niall

---

From: Pekka Savola <[email-masked]>
Date: Thu, 26 Oct 2006 14:33:33 +0300 (EEST)

> It is inconsistent and just wrong.

Sure.. But I'd be interested in knowing whether resolver 
implementations use QTYPE='*' for anything.  Such implementations 
would get broken on some other fronts as well (e.g., A and AAAA 
records under the same name).  AFAICS, it's only used by operators who 
use 'dig'.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Peter Koch <[email-masked]>
Date: Thu, 26 Oct 2006 14:18:44 +0200

> implementations use QTYPE='*' for anything.  Such implementations 

``QTYPE * in apps considered broken'' is on my wishlist (followed by the same
for QTYPE=CNAME and QTYPE=NS, but that are different issues).

> would get broken on some other fronts as well (e.g., A and AAAA 

Yes they do, including failure to deal with truncation and much else.

> records under the same name).  AFAICS, it's only used by operators who 

Unfortunately, no. There are enough mail apps out there using ANY ("*"),
as a look into somewhat detailed stats of your nearest auth server (for
forward zones) will disclose. Still, there's no reason to break the protocol
by making auth servers lie about DNSSEC RR types.

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Thu, 26 Oct 2006 10:05:42 -0400

>Wouter Wijngaards wrote:
...
>>  I disagree.
...
>I fully agree with Wouter and disagree with the recommendation in 3.6.

I completely agree with Peter's fully agreeing with Wouter and 
disagreeing with the recommendation in 3.6.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
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.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 26 Oct 2006 14:00:39 +0000

> Sure.. But I'd be interested in knowing whether resolver implementations use
> QTYPE='*' for anything.  Such implementations would get broken on some other
> fronts as well (e.g., A and AAAA records under the same name).  AFAICS, it's
> only used by operators who use 'dig'.

and by sendmail, who uses it to get the MX and A in one transaction from the
local cache if both happen to be present.  (apparently, enough folks either
didn't have an MX, or had an MX pointing to an A by the same name, to make
this opportunistic logic relevant, and now, much later, it's just how things
are.)  i know of no other app who uses QTYPE=ANY.  i do know that sendmail
would not be bothered by RRSIG, and i do know that sendmail acts properly in
the presence of truncation.  (though i don't know if it ever sets DO or uses
EDNS.)

---

From: Edward Lewis <[email-masked]>
Date: Thu, 26 Oct 2006 15:04:17 -0400

>  Title: Clarifications and Implementation Notes for DNSSECbis

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?