Subject: [dnsext] Follow up on draft-ietf-dnsext-dnssec-registry-fixes

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Jan 2012 17:29:06 -0500

Dear colleagues,

Some time ago, we sent draft-ietf-dnsext-dnssec-registry-fixes-08 to
the IESG.  The consensus on that draft was pretty rough anyway, but
when it got to the IESG there was some very strong opposition.

You may recall that the point of the draft was twofold: to update the
current regstry, and to find one place in which to indicate what
algorithms need to be implemented to maximise interoperability.  (This
was all due to advice we got at one of the IETF meetings some time
ago.)  Objections centred on using a registry to reflect the latter
sort of data, because one cannot conform to a registry but only an
RFC.  While the registry did not actually specify conformance data,
readers pointed out that merely including such in the registry seemed
to head down that road.  

The solution to this has been to break the document in two and treat
the two problems separately.  To that end, Scott Rose (whose patience
with this I must commend) has produced
draft-srose-dnssec-registry-update-00 and
draft-srose-dnssec-algo-imp-status-00.

I would like to ask the WG to review those documents.  I would
especially like to ask those who objected to
draft-ietf-dnsext-dnssec-registry-fixes-08 to review those documents.
If we receive adequate review and, in particular, if we receive
reviews from those previous objectors saying that these new documents
meet their previous objections, then we'll send these along to the
IESG in fulfullment of the charter item, "DNSKEY Registry fixes and
allocation procedure advanced to IESG" (which is marked as done but
which was undone by the rejection of the document).

Thanks, and many happy returns for 2012.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 12 Jan 2012 11:47:48 -0500

Source: http://tools.ietf.org/html/draft-srose-dnssec-registry-update-00

Some contents are formatting, one is about content.

#                                               Trans-
#                                         Zone  action
#      Number  Description     Mnemonic   Sign  Sign     Reference
#      ------  -----------     ------     ----  -----    ---------
#        0      Reserved                                 [RFC4034]
#                                                        [RFC4398]
#        1      RSA/MD5         RSAMD5     N      Y      [RFC3110]
#
#        2      Diffie-Hellman  DH         N      Y      [RFC2539]
#        3      DSA/SHA-1       DSASHA1    Y      Y      [RFC2536]
#        4      Reserved
#        5      RSA/SHA-1       RSASHA1    Y      Y      [RFC3110]
#
#        6      DSA-NSEC3-SHA1  DSA-NSEC3  Y      Y      [RFC5155]
#                               -SHA1
#        7      RSASHA1-NSEC3   RSASHA1-   Y      Y      [RFC5155]
#               -SHA1           NSEC3-
#                               SHA1
#        8      RSA/SHA-256     RSASHA256  Y      *      [RFC5702]
#
#        9      Reserved
#       10      RSA/SHA-512     RSASHA512  Y      *      [RFC5702]
#
#       11      Reserved
#       12      GOST R          GOST-ECC   Y      *      [RFC5933]
#               34.10-2001
#      13-122   Unassigned
#      123-251  Reserved                                 [RFC6014]
#      252      Reserved for    INDIRECT   N      N      [RFC4034]
#               Indirect keys
#       253     private         PRIVATE    Y      Y      [RFC4034]
#               algorithm
#       254     private         PRIVATEOID Y      Y      [RFC4034]
#               algorithm OID
#       255     Reserved

Content - There is no reference for 4,9,11.  I would nominate the RFC 
[that this draft may become] be the reference entry.

And for 13-122 & 123-251, the reference should be the document that 
defines how they are assigned.

255 - should this be RFC 4034 too?

(In order from kind of an issue to would be nicer if...)

Formatting - the use of blank lines is inconsistent.  (After 1, 
there's a totally blank line, not after 0,2,3,...

Formatting - the Numbers column doesn't line up.

Formatting - If the table was wider, could we avoid the wrapping? 
(Perhaps whitespace issues are IANA's.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Vote for the word of the day:
"Papa"razzi - father that constantly takes photos of the baby
Corpureaucracy - The institution of corporate "red tape"
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 12 Jan 2012 23:11:55 -0500 (EST)

Looking just at draft-srose-dnssec-registry-update-00:

1) the propsoed replacement registry no longer mentions that algorithm 
1 has been deprecated (as currently indicated in the IANA registry). 
If that flag is to be removed, perhaps that should be called out in 
section 2.1 as a change.

2) The original IANA registry contains some trailing data re: DH 
primes.  It might be worth explaining/mentioning that.

3) Three algorithms continue to have asterisks in the transaction 
security column (here renamed to Transaction Sign), with a footnote 
(originally from RFC5702) saying "There has been no determination of 
standardization of the use of this algorithm with Transaction 
Security."  Can we say anything more re: these three algorithms' 
usefulness for SIG(0) or TSIG?  If not, we at least need to leave that 
footnote expansion in the registry.

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 13 Jan 2012 06:55:43 -0500 (EST)

I generally support the idea behind this draft (putting current 
recommendation state in an RFC), but I have some minor concerns about 
the specific content:

"The status of RSASHA1-NSEC3-SHA1 is set to RECOMMENDED TO 
IMPLEMENT.  This is due to the fact that RSA/SHA-1 is a MUST 
IMPLEMENT."

I don't follow the logic in the above.  Why does A follow from B?

"Adding a newly specified algorithm to the registry with a compliance 
status SHALL entail obsolescing this document and replacing the 
registry table (with the new algorithm entry)."

I suggest: "Adding...with an implementation status other than OPTIONAL 
SHALL....and publishing a new document with a new complete registry 
table."

Throughout this document, "implementation status", "compliance 
status", and "implementations compliance status" appear.  I don't 
understand the difference between the three.  If there is none, pick 
one and stick to it.

In security considerations: "This document replaces the Domain Name 
System (DNS) Security Algorithm Numbers registry."  I don't think you 
intended to write that in this document.

-- Sam

---

From: Steve Crocker <[email-masked]>
Date: Fri, 13 Jan 2012 07:23:34 -0500

Sam,

Thanks for your comments.  Scott and I will work on these.

Steve

On Jan 13, 2012, at 6:55 AM, Samuel Weiler wrote:

> I generally support the idea behind this draft (putting current recommendation state in an RFC), but I have some minor concerns about the specific content:
> 
> "The status of RSASHA1-NSEC3-SHA1 is set to RECOMMENDED TO IMPLEMENT.  This is due to the fact that RSA/SHA-1 is a MUST IMPLEMENT."
> 
> "Adding a newly specified algorithm to the registry with a compliance status SHALL entail obsolescing this document and replacing the registry table (with the new algorithm entry)."
> 
> I suggest: "Adding...with an implementation status other than OPTIONAL SHALL....and publishing a new document with a new complete registry table."
> 
> Throughout this document, "implementation status", "compliance status", and "implementations compliance status" appear.  I don't understand the difference between the three.  If there is none, pick one and stick to it.
> 
> In security considerations: "This document replaces the Domain Name System (DNS) Security Algorithm Numbers registry."  I don't think you intended to write that in this document.
> 
> -- Sam
>