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

From: [email-masked]
Date: Wed, 06 Jul 2011 06:50:12 -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-02.txt
	Pages           : 8
	Date            : 2011-07-06

   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
   cryptographic algorithms they support.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-signal-02.txt

---

From: Scott Rose <[email-masked]>
Date: Wed, 6 Jul 2011 10:00:47 -0400

An updated version of the algo-signal draft to address the issues in WGLC.  Specific changes:

1.  Changed the wording in 3.4.1 to remove the RFC2119 wording on setting the DO bit.  

2. Changed section 4 wording to indicate DNS proxy systems and added a ref to RFC 5625.

3. fixed some typos and minor wording changes to stress that the DAU option is for signaling only and does not specify any change to how servers construct a response.

Scott

Begin forwarded message:

> From: [email-masked]
> Date: July 6, 2011 9:50:12 AM EDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-02.txt
> 
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Warren Kumari <[email-masked]>
Date: Wed, 13 Jul 2011 15:53:55 -0400

> 3. fixed some typos and minor wording changes to stress that the DAU option is for signaling only and does not specify any change to how servers construct a response.

Oooh, I like this version....

Some simple nits:

Section1: Introduction:

O: "for use with DNSSEC (see . "
C: Somethings missing here :-P

O: "by which a client query can signal a set of algorithms it implements."
P: "by which a client query can signal a set of algorithms which it implements.
C: or "that" or something ?

Section 2
O: "for the DNSSEC Algorithm Understood (DAU)"
P: for the DNSSEC Algorithms Understood (DAU)"
C: Plural?

O: "DNSSEC algorithm codes are 1 octet long so this value is the number of octets."
P: ""
C: Is this sentence needed? I don't have proposed text, but I found it broke the flow of the text...

Section 3.1:
O: "So optimal setting of the DAU"
P: "Optimal setting of the DAU"

Section 3.2:
O: "This way thee validating stub resolver"
P: "This way the validating stub resolver"
C: 'thee" is *so* last century...

Section 3.4.1:
O: "A validating recursive resolver sets..."
C: It *might* be interesting to somewhere also include a flag saying if the DAU was included because the client did so, or if the recursive did so because of local policy... 

Section 6:
O: "Zone administrators that are planning"
P: "Zone administrators who are planning"
C: Just sounds better (IMO).

W

---

From: Dick Franks <[email-masked]>
Date: Thu, 14 Jul 2011 19:59:59 +0100

Scott, Patrik,

I find myself roused from dnsext lurking mode by what  appears to be a
conflict between draft02 of this proposal and the requirements of
RFC2671, which has somehow slipped through review.

RFC2671 defines OPT record wire-format <rdata> to be a list of
elements of the form:

    <option-code><option-length>[<option data>]

This permits an uncomprehending implementation to parse a list
containing options it does not recognise. For this to work,
implementations must regard <option-data> as opaque.

Using the following example based on the text of section 2 of draft02,

    DAU  2  [ RSASHA256 RSASHA1 ]  1  [RSASH1]

The uncomprehending implementation in my brain parses this as:

    <option-code> = DAU

    <option-length> = 2

    <option-data> = ( RSHASHA256 RSASHA1 )

    <option-code> = 1

    <option-length> = RSASHA1

game over!

Either, the internal structure of DAU will need to be changed to
conform to RFC2671,

    DAU  5  2  [ RSASHA256 RSASHA1 ]  1  [RSASH1]

or the proposal reworked to define two new options:

    ALGU  2  [ RSASHA256 RSASHA1 ]

    HASHU  1  [RSASH1]

which, separated, may also find applications beyond DNSSEC.

I apologise for raining on your parade.

--Dick

---

From: Dick Franks <[email-masked]>
Date: Thu, 14 Jul 2011 23:07:08 +0100

<option-code> = DAU

   <option-length> = 2

   <option-code> = 1

game over!

   HASHU  1  [RSASH1]

--Dick

---

From: Dick Franks <[email-masked]>
Date: Fri, 15 Jul 2011 16:43:51 +0100

Scott, Patrik,

   <option-code> = DAU

   <option-length> = 2

   <option-code> = 1

game over!

   HASHU  1  [RSASH1]

--Dick

---

From: Scott Rose <[email-masked]>
Date: Fri, 15 Jul 2011 14:47:56 -0400

Thanks for the comment.  I will have to double check and fix the example as necessary.

Scott

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 18 Jul 2011 09:18:00 +0200

Sorry for not responding earlier, but I have been on PTO... Scott, thanks for having a look at this.

   Patrik Fältström
   Distinguished Consulting Engineer
   Office of the CTO

   For corporate legal information go to:
   http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Dick Franks <[email-masked]>
Date: Mon, 18 Jul 2011 11:19:23 +0100

The issue here is (in)compatibility with RFC2671(4.4) and
RFC2671bis(6.2), not a problem with the example.

--Dick