Subject: [dnsext] Last Call: <draft-ietf-dnsext-dnssec-registry-fixes-08.txt> (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 26 May 2011 08:22:57 -0700

The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA
   Registry'
  <draft-ietf-dnsext-dnssec-registry-fixes-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-06-09. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The DNS Security Extensions (DNSSEC) requires the use of
   cryptographic algorithm suites for generating digital signatures over
   DNS data.  There is currently an IANA registry for these algorithms
   that is incomplete in that it lacks the implementation status of each
   algorithm.  This document provides an applicability statement on
   algorithm implementation compliance status for DNSSEC
   implementations.  This status is to measure compliance to this RFC
   only.  This document replaces that registry table with a new IANA
   registry table for Domain Name System Security (DNSSEC) Algorithm
   Numbers that lists (or assigns) each algorithm's status based on the
   current reference.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-fixes/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-fixes/

No IPR declarations have been submitted directly on this I-D.

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

---

From: Pete Resnick <[email-masked]>
Date: Mon, 30 May 2011 18:53:38 -0500

On 5/26/11 10:22 AM, The IESG wrote:
> final comments on this action.

Speaking as individual, not AD.

The document says in section 2.1:

> 2.1.  Updates and Additions
>
>    This document updates three entries in the Domain Name System
>    Security (DNSSEC) Algorithm Registry.  They are:
>
>    The description for assignment number 4 is changed to "Reserved until
>    2020".
>
>    The description for assignment number 9 is changed to "Reserved until
>    2020".
>
>    The description for assignment number 11 is changed to "Reserved
>    until 2020".

OK, I give up....What happens in the year 2020? The end of the Mayan 
calendar? Another prediction of the coming apocalypse? Oprah will return?

Without the jokes: I find "due dates" in standards completely 
ridiculous, without any purpose, and object strongly to them. I cannot 
see what the dates add to the reservation of these code points, and 
there is no explanation of dates (let alone these *particular* dates) in 
the draft. These either need to be explained in excruciating detail or 
removed.

>    Registry entries 13-251 remains Unassigned.

That would be a surprise, since the current registry at

<http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml>

says:

13-122    Unassigned
123-251    Reserved                [RFC6014][standards track]

This document makes a change to 123-251. That either needs justification 
in the document or needs to be reverted.

In my (personal) opinion, this document is not ready for publication in 
its current form.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 31 May 2011 07:12:08 -0400

On Mon, May 30, 2011 at 06:53:38PM -0500, Pete Resnick wrote:

> ridiculous, without any purpose, and object strongly to them. I
> cannot see what the dates add to the reservation of these code
> points, and there is no explanation of dates (let alone these
> *particular* dates) in the draft. These either need to be explained
> in excruciating detail or removed.

These are all typecodes that have "leaked". 

In the case of 4, it was "reserved for elliptic curve" but it is clear
that there may be more than one elliptic curve algorithm and we can't
be sure which curve might be being tested with this.

In the case of 9 and 11, it was due to a keen implementer of SHA2.
The SHA2 specification originally left WGLC with two numbers for each
of SHA256 and SHA512.  This was to "alias" NSEC vs. NSEC3 (see how
SHA1 is handled).  After WGLC, some WG participants objected
vociferously, and it became clear that WG consensus was against such
aliasing.  But one implementation had already shipped with the four
assignments in place.

We picked 2020 as a time by which we figured any software using any of
this would have to have been updated.  My personal preference would
have been to specify that the four code points were all reserved until
all other code points were used, but that seemed too complicated a
rule so we picked 2020.

Why do you think this all needs to be outlined in the draft?  Why do
such rules (which are, after all, just destined for a registry) need
to be given a rationale?  

> That would be a surprise, since the current registry at

This is my fault; I missed it in my own review.  The draft will be
updated to reflect the changes to the registry made by RFC 6014 (which
reserves 123-251).

Thanks for catching this.

A (as document shepherd)

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 31 May 2011 07:42:28 -0700

> all other code points were used, but that seemed too complicated a

It sounds like Pete is saying "picking 2020 is complicated", so maybe the original idea ("until all other code points are used") is better.

> such rules (which are, after all, just destined for a registry) need

So that someone evaluating the document can understand the rationale for the decision points in the document. Switching to "until all other code points are used" is self-explaining.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 31 May 2011 13:54:14 -0400

On Tue, May 31, 2011 at 07:42:28AM -0700, Paul Hoffman wrote:
 
> It sounds like Pete is saying "picking 2020 is complicated", so
> maybe the original idea ("until all other code points are used") is
> better.
> 
> So that someone evaluating the document can understand the rationale
> for the decision points in the document. Switching to "until all
> other code points are used" is self-explaining.

In that case, I think the right answer is to do something along the
following lines:

    1.  Alter the relevant passage in section 2.1 as follows:

        The description for assignment number 4 is changed to "Reserved".

        The description for assignment number 9 is changed to "Reserved".

        The description for assignment number 11 is changed to "Reserved".

    2.  Alter the new registry table in the same way.

    3.  Add a subsection 2.4, "Rationale for reserving assignments 4,
        9, and 11", as follows:

        Assignment numbers 4, 9, and 11 are believed to have been used
        in software released on the Internet prior to the publication of this
        memo, which is why they are hereby reserved.  The assignments
        were never requested of nor made by IANA.

The point of (3) is to make the reasoning clear and to make it clear
to future IETF participants that they could plausibly reuse those code
points after sufficient time had passed.  (We have a problem in the
DNS of much of the reasoning being contained in our oral tradition,
and I'd like to break that cycle.)

How's that sound?

A