Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-08.txt

From: [email-masked]
Date: Tue, 14 Aug 2012 10:22:15 -0700

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           : Signaling Cryptographic Algorithm Understanding in DNSSEC
	Author(s)       : Steve Crocker
                          Scott Rose
	Filename        : draft-ietf-dnsext-dnssec-algo-signal-08.txt
	Pages           : 8
	Date            : 2012-08-14

Abstract:
   The DNS Security Extensions (DNSSEC) were developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures.  These digital signatures can be generated using
   different algorithms.  This draft sets out to specify a way for
   validating end-system resolvers to signal to a server which digital
   signature and hash algorithms they support.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-signal-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsext-dnssec-algo-signal-08

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Scott Rose <[email-masked]>
Date: Tue, 14 Aug 2012 13:29:26 -0400

New version that addresses the comments received from the -07 version.

Significant changes:

1. Ordering of algorithm codes:  changed text to stress that the order can be arbitrary and servers should not infer preference, only that the client signals understanding.

2. Recursive Resolver setting option:  Draft now says that recursive resolvers should set the list to be the union of their list and the list of the stub, if present.  If no list is present, recursive resolvers free to put their own list in full.

3. Text added to stress that the EDNS options are all OPTIONAL, do not have to all appear together, but each option can only appear once.

4. Text added to Security Considerations that the options may give an attacker clues to the client version based on the option and lists.  

Comments/questions welcome

Scott & Steve

On Aug 14, 2012, at 1:22 PM, [email-masked] wrote:

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================

---

From: Dick Franks <[email-masked]>
Date: Wed, 22 Aug 2012 20:02:51 +0100

Scott & Steve,

[2, para 4]

   ALG-CODE is the list of assigned values of DNSSEC zone signing
   algorithms, DS hash algorithms, or NSEC3 hash algorithms (depending
   on the OPTION-CODE in use) that the client declares to be supported.
   The order of the code values can be arbitrary and SHOULD NOT be used
   to infer preference.

WG seems to agree that there is no information to be gleaned from the
order in which codes appear in the list. The requirement can therefore
be strengthened from SHOULD to MUST.

The present wording implies that the order will remain the same from
one occasion to another, i.e. sorted using some (arbitrary) ordering
relation.  There is no requirement that it should.

Suggest:
   ...
   The list of algorithm codes is unordered and MUST NOT be used
   to infer preference.

[3, para 1]

   A validating end-system resolver sets the DAU, DHU and/or N3U option,
   or combination thereof in the OPT meta-RR when sending a query.  The
   validating end-system resolver sets the value(s) in any arbitrary
   order.  The validating end-system resolver MUST also set the
   DNSSEC-OK bit [RFC4035] to indicate that it wishes to receive DNSSEC
   RRs in the response.

Second sentence is redundant, covered by section 2.

[3.1.2]

 The DAU, DHU and N3U EDNS options are NOT RECOMMENDED for non-
   validating stub resolvers.

As non-validating stub implements no algorithms at all, why does this
say "are NOT RECOMMENDED" instead of "MUST NOT be used"?

Dick