Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-registry-fixes and draft-ietf-dnsext-dnssec-alg-allocation WGLC announcement

From: Samuel Weiler <[email-masked]>
Date: Sat, 9 Jan 2010 13:21:09 -0500 (EST)

Tackling these two docs separately.  First registry-fixes:

I think registry-fixes needs changes.

Adding the "requirement status" column to the registry is a fine idea 
(note the change in terminology suggested by Brian Wellington, which I 
support).

I'm concerned about the metric for making changes to the requirement
status: taken together, these two docs would allow an independent
submission (=RFC Editor stream document) to create a "MANDATORY"
algorithm.  I think that's bad.

It also looks like there's also a possibility that an informational 
RFC or independent submission could change the requirement status of 
new algorithms, even if those were defined on the standards track.  I 
propose the following:

"The requirement status for all new algorithms will be OPTIONAL unless 
a Standards Track document changes that (possibly including the 
Standards Track document defining the algorithm).  Only a Standards 
Track document may make an algorithm ENCOURAGED or MANDATORY or remove 
the MANDATORY or ENCOURAGED designation."

This suggests giving IANA a more complicated assignment metric for 
this registry: "assignments" are RFC Required, but changes in the 
requirement status field are still "Standards Action".

I'm also wondering where the proposed requirement status entries came 
from.  For instance, RSA/SHA-256 is shown as OPTIONAL, but RFC5702 
uses SHOULD, which suggests the term (per 
ogud-iana-protocol-maintenance) should be ENCOURAGED. 
(dnssec-bis-updates-09 also says this, in Section 2.)  Similarly, I'm 
not recalling that we've issued any document declaring RSA/MD5 
OBSOLETE.  Making that change here is fine, but it should be called 
out as a change.  And if these two are off, then are there errors 
elsewhere?

-- Sam

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 11 Jan 2010 11:19:58 +0100

On 01/09/2010 07:21 PM, Samuel Weiler wrote:
>
> It also looks like there's also a possibility that an informational RFC
> or independent submission could change the requirement status of new
> algorithms, even if those were defined on the standards track.  I
> propose the following:
> 
> "The requirement status for all new algorithms will be OPTIONAL unless a
> Standards Track document changes that (possibly including the Standards
> Track document defining the algorithm).  Only a Standards Track document
> may make an algorithm ENCOURAGED or MANDATORY or remove the MANDATORY or
> ENCOURAGED designation."
> 

+1

> from.  For instance, RSA/SHA-256 is shown as OPTIONAL, but RFC5702 uses
> SHOULD, which suggests the term (per ogud-iana-protocol-maintenance)
> should be ENCOURAGED. (dnssec-bis-updates-09 also says this, in Section
> 2.)  Similarly, I'm not recalling that we've issued any document
> declaring RSA/MD5 OBSOLETE.  Making that change here is fine, but it
> should be called out as a change.  And if these two are off, then are
> there errors elsewhere?
> 

+1 on both suggestions, assuming that for 2) you mean it should be
DISCOURAGED, or the text in section 4 should be removed since this would
make a new statement on algorithm strengths.

That prompted me to take a quick look at the normative-referenced but
still very draft-y draft-ogud-iana-protocol-maintenance-words-02.
DISCOURAGED is MUST-implement-this but discouraged-to-use, while
ENCOURAGED is SHOULD-implement-this. That first one sounds wrong (note
that i haven't followed discussion on that one at all, or seen it actually).

Should we even publish this draft (reg-fixes) before maintenance-words
is out? Not that I advocate more slowness in general, but it seems wrong
to make a standards track document that adds a column with values that
aren't defined yet...

And about alg-allocations, i withdraw my earlier opposition about the
reserved-for-testing allocations, and support this document going forward.

Jelte

---

From: "Rose, Scott W." <[email-masked]>
Date: Mon, 11 Jan 2010 07:25:42 -0500

> the MANDATORY or ENCOURAGED designation."

Yeah, I thought about that while I was writing it, but never got around to
asking the WG for ideas/consensus.  I'll work that text in.

Part of the hold on the ogud-maintenance-words draft right now is the dual
use of OPTIONAL (RFC 2119 and the draft).  Suggestions were:  DESCRESIONARY,
ELECTIVE, or something else.  This isn't strictly a DNS issue.

> out as a change.  And if these two are off, then are there errors

The table is unchanged from the -00 draft which is
pre-ogud-iana-protocol-maintenance.  So those words didn't "exist" :)  Some
of the ones listed as "OPTIONAL" should be "ENCOURAGED".

Scott

> -- Sam

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
Google Voice: +1-571-249-3671

http://www.dnsops.gov/
===================================

---

From: "Rose, Scott W." <[email-masked]>
Date: Mon, 11 Jan 2010 07:33:15 -0500

On 1/11/10 5:19 AM, "Jelte Jansen" <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> that i haven't followed discussion on that one at all, or seen it actually).

We are using "DISCOURAGED" to mean it is in use, but the community is trying
to phase it out, so for backwards compatibility new implementations would
need to understand it, but shouldn't use it going forward (if possible).
While ENCOURAGED means it isn't widely used now, but the community thinks it
is a good option/algorithm/whatever so this is the trial stage.  If no
problems are seen, expect it to become a new MANDATORY thing soon (for some
definition of 'soon').

> to make a standards track document that adds a column with values that

Since we would be using the new words here, I hate to publish this before
the ogud-iana-protocol-maintenance-words draft.  Maybe at the same time.
Hopefully the maintenance words draft will go quickly and this can follow.

Scott

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAktK+04ACgkQ4nZCKsdOncXPZgCgrqAacH+0bcaLJbmiWX0ylE6O
> 22MAoJ/6UMwD/u1UhFj8DLlFtfY3TXCz
> =x2xZ
> -----END PGP SIGNATURE-----
> 
> 

http://www.dnsops.gov/

---

From: Samuel Weiler <[email-masked]>
Date: Sat, 9 Jan 2010 19:01:53 -0500 (EST)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

On Sat, 19 Dec 2009, Andrew Sullivan wrote:

> Please note that draft-ietf-dnsext-dnssec-alg-allocation-00.txt alters
> the way algorithm identifiers are assigned, and has a fail-safe
> provision in it to protect the number space as it starts to be
> depleted.  It is particularly important that the WG decide whether
> that provision is a good one and, if so, if it is set at the right
> level.

I'm concerned that the best way we've found, to date, of versioning 
the DNSSEC protocol is using algorithm numbers, and that we may find 
ourselves consuming more algorithm numbers for that purpose in the 
future That said, I'm content to let this change go through with some 
minor changes.

Consistent with my recommendation re: registry-fixed and requirements 
status, I'd like to see this document repeat my proposed changes: 
"Unless specified in a Standards Track RFC, new algorithms will have a 
requirements status of OPTIONAL.  Only a Standards Track RFC may set 
or change a requirements status of ENCOURAGED or MANDATORY."

And, in keeping with the proposed fail-safe, I'd like to see half of 
the registry marked as "reserved".  That at least reminds people to 
come back at read this doc at the appropriate point.

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 11 Jan 2010 10:09:46 -0500 (EST)

>> may make an algorithm ENCOURAGED or MANDATORY or remove the MANDATORY or

Thank you.

I had misunderstood how ogud-iana-... defined "DISCOURAGED".  That 
definition is bizarre.  It we're going to use it, it seems that 
DISCOURAGED needs to go in the above list, too.  But I'd rather see us 
not use that bizarre definition, even if it means defining the terms 
ourselves in this document.

>> from.  ...  are
> +1 on both suggestions, assuming that ...

Independent of the particular suggestions, I was (and am) hoping that 
someone (Scott?) will make sure each of these line items is correct 
and document that (in this doc?).

> that i haven't followed discussion on that one at all, or seen it actually).

As above, this sounds bizarre to me.  So bizarre that I'm dubious 
about using these definitions.  Can we get by with defining our own 
terms in this doc, where necessary?

-- Sam

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 11 Jan 2010 10:58:14 -0500

At 10:09 11/01/2010, Samuel Weiler wrote:
>DISCOURAGED needs to go in the above list, too.  But I'd rather see 
>us not use that bizarre definition, even if it means defining the 
>terms ourselves in this document.

send text.

>Independent of the particular suggestions, I was (and am) hoping 
>that someone (Scott?) will make sure each of these line items is 
>correct and document that (in this doc?).
>

If the definitions are useless and can not be used in this context
then it is dubious that the definitions can be used in a similar
context. The point of having the two drafts is for one to
have the practice and the other one demonstrating in practice that
a vocabulary is useful.

Lets fix the definitions,

         Olafur

---

From: "Rose, Scott W." <[email-masked]>
Date: Mon, 11 Jan 2010 11:11:31 -0500

> and document that (in this doc?).

I will add that.  The most recently spec'ed algorithms (RSA/SHA-256 &
SHA-512) did not give any status, so I was going with the default OPTIONAL
unless there is some stronger group consensus to make it mandatory to
implement.

The basis was RFC 4034 for the basic algorithms.  RSA/SHA-256/512 were added
later so OPTIONAL.  I haven't heard a yay/nay for the others.

Scott

http://www.dnsops.gov/

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 11 Jan 2010 14:35:28 -0500

On Mon, Jan 11, 2010 at 5:19 AM, Jelte Jansen <[email-masked]> wrote:

> > ...

> that i haven't followed discussion on that one at all, or seen it

I suggest changing to the notation used in at least some security RFCs: If
the idea is to give the the current estimate of the direction of change in
the implementation requirement, when that estimate is certain enough, then
just do that explicitly. A suffix "+" indicates that the implementation
requirement is likely to get stronger. A minus, the opposite. No suffix is
required and none would be specified unless there was judged to be
reasonable expectation that it would change reasonably soon.

So, instead of "DISCOURAGED", you can have MUST- if it was mandatory and is
expected to change to SHOULD or worse, or SHOULD- if it was SHOULD and
expected to change to MAY or worse. So something expected to become
mandatory would normally be SHOULD+ and if some problem is encountered
before it is changed to mandatory, there is no problem putting thought a
change to strip the "+" or to just change it to MAY or MUST NOT or
whatever...

I suppose I should go post this directly to the
ogud-iana-protocol-maintenance-words draft...

Thanks,
Donald

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Wed, 13 Jan 2010 17:23:14 -0500

I have read both documents and support them going forward. I do have a  
couple of comments though:

1) I feel that "RFC required" is not a very high barrier in and of  
itself. We do have the control where the working group will have to re- 
evaluate the requirements when the registry is half full, but we have  
no means to enforce this control. I therefore agree with Sam's  
suggestion of making about half of these identifiers RESERVED, so that  
we're forced to revisit this requirement at the appropriate time.  
Alternatively, we could have the additional requirement that any  
algorithm that is to be added to the registry as part of the "RFC  
required" route must also be reviewed for appropriateness by an expert  
appointed by the WG chairs. This would prevent well-meaning  
cryptographers from aggressively consuming the first 50% of  
identifiers before the WG gets a chance to react. Note that I support  
the document(s) going forward even if this change is not made.

2) I also support Sam's suggestion of making all "RFC required"  
algorithms OPTIONAL, unless that status is changed by Standards action.

Suresh

On Dec 19, 2009, at 12:23 PM , Andrew Sullivan wrote:

> Dear colleagues,
>
> This email begins a three week Working Group Last Call for the two
> documents draft-ietf-dnsext-dnssec-alg-allocation-00.txt and
> draft-ietf-dnsext-dnssec-registry-fixes-01.txt.  We are calling these
> documents together because in our view they naturally complement one
> another.
>
> This WGLC will end at 17:00 EST on 2010-01-09.  Participants are
> reminded that the WG's process rules require at least five people to
> say that they have read the document, and that they support it, before
> it can be forwarded to the IESG for publication.  We have the list of
> volunteers who previously agreed to read this document, and if you
> don't perform the review as expected, we'll approach you directly.
>
> Participants are reminded that _ad hominem_ attacks are not permitted,
> and that they should confine themsleves to the technical merits of the
> drafts.
>
> I will be the document shepherd for these drafts.
>
> Best regards,
>
> Andrew
>
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
>

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 15 Jan 2010 12:30:04 -0800

I've read the dnsext-dnssec-alg-allocation document and support it's
forward progress and have the following comments to offer:

First, I think Sam's and the following suggestions have been spot on for
fixing the conflicting of standards and non-standards with respect to
requirement levels.

I had also wanted to deleted the word "about" from "about half full" but
after catching up on the discussion I think the proposal of reserving
half the space is much better than attempting to trigger a review at
"about half full" time.  Reserving will make sure the review happens.

Other editorial comments:

1) I'd suggest a global search and replace of "rule" with "requirement"
   which would make it more consistent with the way most IETF documents
   seem to be written.  "rule" is much less common and I don't think is
   even used to refer to the requirement we're changing in the first
   place.

2) A number of places has "on Standards Track" which I think is also
   less consistent with the way it's commonly phrased and should be "on
   *the* Standards Track".

   There are a few instances of it missing in the RFCs, but by far the
   more common usage is to treat "Standards Track" as a noun and require
   the article:

   #  grep -i 'on standards track' *.txt | grep -i -v 'non standards track' | wc -l
   8

   # grep -i 'on the standards track' *.txt | wc -l
   162

3) Section 2, bullet 1, last sentence.  Suggested replacement to drop
   "an" and "situation, and" brings it to:

   Another example is that the algorithm might have unclear intellectual
   property rights that prevents the algorithm from being put on the
   Standards Track.

4) Section 2, bullet 2: remove "quite" from "quite restricted" since
   "quite" is very subjective.  In fact, if the number space was "quite
   restricted" that'd lead me to think we shouldn't be opening it up in
   the first place!

5) Section 2, paragraph starting with "Because" remove "essentially"
   from the last sentence.

6) Section 4, first paragraph, last sentence:

     "The registration procedure for values that were not assigned
     before this document is published is "RFC Required".

   That doesn't make sense to me as is.  I'm not sure whether the
   sentence is trying to state history or whether it's trying to assign
   "RFC Required" to numbers that were assigned before this document is
   published.  I think the second, in which case it should be:

     "The registration procedure for values that were --- assigned
     before this document is published is "RFC Required".

   Maybe I'm missing something here; either way I'm confused!

7) Section 5 after "... weaker." I'd suggest adding:

   Conversely, algorithms that are on the Standards Track should not
   necessarily be considered better than algorithms that are not on the
   Standards Track.

-- 
Wes Hardaker
Cobham Analytic Solutions