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

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Jun 2011 11:03:57 -0400

At 8:22 -0700 5/26/11, The IESG wrote:
>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

As someone that would implement against this document, I find its 
role confusing.

The title is
#   Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA
#                                Registry

Is this title meant to tell me that this is defining or redefining 
the DNSKEY Algorithm Registry run by IANA?  The "Applicability" part 
is a little confusing.

I mention this because of the following text in the Introduction:

# This document replaces the original list with a new table that includes the
# current compliance status for certain algorithms.
#
# This compliance status indication is only to be considered for
# implementation, not deployment or operations.  Operators are free to
# deploy any digital signature algorithm available in implementations
# or algorithms chosen by local security policies.  This status is to
# measure compliance to this RFC only.

The first sentence seems to be refining the registry.  Then there are 
words saying that this document relates only to code development and 
not use.  The final sentence mentions "compliance to this RFC" and 
this is where I lose it.

I am all for a document to define a registry.  And in my experience, 
a registry is supposed to map objects to entities (in this case 
DNSKEY algorithms to values in a protocol field) in a fairly neutral 
way.

I am all for a document to define an operational profile, requiring 
certain choices to be made to be conformant to some standard of 
service delivery.  I would like to be able to advertise that "we 
conform with RFC wxyz" and have that say we operate with certain 
algorithms.

But I don't think it is correct to do both in the same document. 
This gets very confusing when trying to deal with RFPs (Request for 
Propsals and the like) that list RFCs that should be complied with. 
One issue is the conflict between the neutrality of a registry's 
function and the advocacy of a profile document.

I fail to see the rationale that all implementations must support 
specific algorithms.  (Interoperability doesn't need that.)  I 
understand that if the topic is "general purpose implementations" 
there are a common set of algorithms such implementations should 
support.  There are, however, turnkey DNS deployments in which these 
algorithms may not make sense.  Any implementation is free to ignore 
an algorithm or to treat responses as "bad" if it wants to.

A strong tenet of the DNSSEC policy is that "local policy" is the 
trump card in all security decisions.  The cache that is being 
protected gets to choose it's own policy.  By creating a registry 
that commands what is implemented and not implemented, there's a 
conflict with "local policy".  I don't mean that the implementation 
of the cache is restricted, but the authority and other middle DNS 
servers are restricted.

My recommendation is to turn this document into something called a 
"Public Internet General Purpose DNSKEY ALgorithm Profile", make it a 
BCP (that can be updated) and let it summarily list the algorithms 
that should or shouldn't be included.  Leave these designations out 
of the registry (table) and don't have this document try to change 
the registry.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?

---

From: Scott Rose <[email-masked]>
Date: Wed, 1 Jun 2011 13:18:11 -0400

On Wed, Jun 1, 2011 at 11:03 AM, Edward Lewis <[email-masked]> wrote:

> As someone that would implement against this document, I find its role
> confusing.
>
> The title is
> Is this title meant to tell me that this is defining or redefining the
> DNSKEY Algorithm Registry run by IANA?  The "Applicability" part is a little
> confusing.
>

Technically redefining if you want to split hairs.

> The first sentence seems to be refining the registry.  Then there are words
> saying that this document relates only to code development and not use.  The
> final sentence mentions "compliance to this RFC" and this is where I lose
> it.
>
> I am all for a document to define a registry.  And in my experience, a
> registry is supposed to map objects to entities (in this case DNSKEY
> algorithms to values in a protocol field) in a fairly neutral way.
>
> I am all for a document to define an operational profile, requiring certain
> choices to be made to be conformant to some standard of service delivery.  I
> would like to be able to advertise that "we conform with RFC wxyz" and have
> that say we operate with certain algorithms.
>
> But I don't think it is correct to do both in the same document. This gets
> very confusing when trying to deal with RFPs (Request for Propsals and the
> like) that list RFCs that should be complied with. One issue is the conflict
> between the neutrality of a registry's function and the advocacy of a
> profile document.
>
> I fail to see the rationale that all implementations must support specific
> algorithms.  (Interoperability doesn't need that.)  I understand that if the
> topic is "general purpose implementations" there are a common set of
> algorithms such implementations should support.  There are, however, turnkey
> DNS deployments in which these algorithms may not make sense.  Any
> implementation is free to ignore an algorithm or to treat responses as "bad"
> if it wants to.
>
> This doc doesn't change that at all.  You can still implement whatever you
want, just not claim conformance to this doc.

> A strong tenet of the DNSSEC policy is that "local policy" is the trump
> card in all security decisions.  The cache that is being protected gets to
> choose it's own policy.  By creating a registry that commands what is
> implemented and not implemented, there's a conflict with "local policy".  I
> don't mean that the implementation of the cache is restricted, but the
> authority and other middle DNS servers are restricted.
>
> Local policy is already restricted by implementations.  This doc really
doesn't change that - it only really reflects the current state of crypto in
DNSSEC.  Something that has been more oral history than written down.

> My recommendation is to turn this document into something called a "Public
> Internet General Purpose DNSKEY ALgorithm Profile", make it a BCP (that can
> be updated) and let it summarily list the algorithms that should or
> shouldn't be included.  Leave these designations out of the registry (table)
> and don't have this document try to change the registry.
>
>
Our main reason for replacing the registry table with a doc containing a new
table was that not all implementors may be good at sorting through the IETF
archives looking for every DNSSEC related RFC and BCP.  Have a simple table
at a well known repository will hopefully reduce that document hunt.

Scott

> Edward Lewis             NeuStar                    You can leave a voice
> message at +1-571-434-5468
>
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Jun 2011 13:52:17 -0400

> Technically redefining if you want to split hairs.

We could remove the "Applicability Statement" in the title, if that would help.  Ed?

> at a well known repository will hopefully reduce that document hunt.

I think this is the key point, and I want to make it more strongly
than Scott does: we already tried that.  

We have some documents that say which algorithms are mandatory to
implement.  Other RFCs have defined algorithms but were silent on
whether something needed to be implemented -- quite correctly, since
it is meaningless for a document to define what MUST be done for
anything other than conformance with it.  Finally, the DNS world has a
long history of requirements littered throughout various RFCs, but
without a codex that would allow you to find all the RFCs you need to
read to understand what you ought to do for your particular
implementation.

We received feedback at a meeting (in Maastricht, I think, and from
Steve Kent, I think) that the DNSEXT WG should pick some algorithms
and make it clear that those are the ones everyone ought to be able to
use, if they want to be interoperable with everyone else.  We were
also advised to make clear the one(s) we believe to be "up next", on
the grounds that implementers and deployers can be ready.

So, the goal here is threefold: (1) to collect all those MUSTs and
MUST NOTs into one RFC: anything not defined in that RFC as required
is completely optional; (2) to provide a single place where
implementers can find out where that advice is located; (3) to make
sure that we don't somehow end up with conflicting advice.

The list of requirements in this draft satisfies (1).  One conforms to
an RFC, and if it is published as an RFC then this document is the one
to which one should refer in RFPs and so on, assuming one wants this
sort of general-purpose conformance.  (If you only wanted GOST, for
instance, you wouldn't require conformance to this document.  That's
just a different decision.)

Now, of course, (2) could be solved in more than one way.  We could
put up http://tools.ietf.org/wg/dnsext/guide-to-the-perplexed and
include a link to this document (if it becomes an RFC).  But that
would not solve (3).

(3) is the real reason to use the registry for this.  Registries are
not just there to have a single convenient place to look everything
up.  They also exist because they prevent collisions and so on.  Only
one entry can be in the registry for code point _n_.  The "conformance
to RFC TBD1" column is yet anothe such condition: only RFC TBD1 is
allowed to add things to that column.  So if anything comes along and
tries to add things to that column, we know we have a failure, and the
registry entry doesn't get created until the problem is solved.

In this way, the draft is using the registry exactly as it was
intended: it is a control point that makes sure a given assignment
happens in a co-ordinated way.  In this case, the assignment is "DNS
community current best advice about what will be maximally
interoperable."  It's not a blessing; it's just another entry that
ensures co-ordination on the Internet in a way that ensures
interoperability is maximized.

Best,

A (document shepherd)

-- 
Andrew Sullivan
[email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 01 Jun 2011 14:37:57 -0400

On 01/06/2011 11:03 AM, Edward Lewis wrote:
> DNSKEY Algorithm Registry run by IANA? The "Applicability" part is a
> little confusing.
>

See:
RFC2026/BCP9  section 3.2  Applicability Statement (AS)

	Olafur

---

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Jun 2011 15:28:46 -0400

At 13:18 -0400 6/1/11, Scott Rose wrote:

>This doc doesn't change that at all.  You can still implement whatever
>you want, just not claim conformance to this doc.

If that's the case, then there should be no IANA changes from this document.

>Our main reason for replacing the registry table with a doc containing a
>new table was that not all implementors may be good at sorting through
>the IETF archives looking for every DNSSEC related RFC and BCP.  Have a
>simple table at a well known repository will hopefully reduce that
>document hunt.

I think there's a misunderstanding about the role of a registry table 
and a profile when it comes to conformance.  E.g., look at the DNS 
registry of RR type codes.  Implementations would support a type by 
using the directions in the documents indicated in the last column. 
This does not indicate whether the type is a good idea to support or 
not, just indicates the definition.

There is no list of types that "are actually in use."  That would be 
nice to have.  If this document is trying to fill that role, then 
fine, but don't change the underlying registry table.

As far as "Applicability Statement" in the title, which Olafur notes 
is defined in RFC 2026 (an unreferenced document, need to add that 
then), then make this document an applicability statement and not a 
change to a registry.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Jun 2011 15:45:48 -0400

>We could remove the "Applicability Statement" in the title, if that would

I think the issue is where to put what conventional wisdom considers 
the current algorithms to use.  No matter how much I think about it, 
I think putting this in a registry is a mistake.

The problem is that a registry is a current state of affairs.  It is 
not versionable.  I don't say my implementation is compliant with the 
IANA registry of 1999.  If I did, there's no way to check that. 
However, I can say my implementation is compliant (as in built to the 
contents of) RFC 2065.  'Course, RFC 2065 is obsolete, but my code 
may not have been changed.  If I re-implement to meet RFC 2535 and 
then later to RFC 4033-4035, you can verify this via the history of 
documents.  The types in the IANA registry show the current 
definitions, but the RFCs keep the history.

>the grounds that implementers and deployers can be ready.

Then just issue a document called "DNSEXT's Preferred Algorithms 
2011" and make it an RFC.  This way, in 10 years, we can sit back and 
laugh at what was fashionable back in the day.

>sure that we don't somehow end up with conflicting advice.

That would be nice, I just think a registry is the wrong place to put 
that - because registries change and old (deployed) implementations 
don't.

>interoperability is maximized.

But the "current best advice" changes.  And old versions of software don't.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Jun 2011 16:33:55 -0400

On Wed, Jun 01, 2011 at 03:45:48PM -0400, Edward Lewis wrote:

> That would be nice, I just think a registry is the wrong place to
> put that - because registries change and old (deployed)
> implementations don't.

> But the "current best advice" changes.  And old versions of software don't.

Right.  And the RFC to which those old versions of software conforms
doesn't change either.

You cannot claim conformance to the registry, because registries are
not an archival series and because they do change.  We agree on that.
But you don't seem to think that the registry of RRTYPE code points
changing is a bad idea, even though early software didn't have the
RRTYPE for DNAME or DNSKEY.  In the same way, the registry of these
algorithm types might change, and it wouldn't matter.  But nobody is
allowed to put _anything_ into that "Compliance to RFC TBD1" column.
If the WG wants in future to make some shiny new algorithm
"RECOMMENDED TO IMPLEMENT" according to the latest guidance, and wants
that to be reflected in a registry somewhere, then the answer is to
write a new document that obsoletes the draft we're talking about, and
completely replace the typecode registry again, with the new values
(presumably, a new column, called "Compliance to RFC TBD2", and
dropping the analagous column from the current version).

I believe that nothing anywhere in the document suggests that one
ought to guage conformance of software against the registry, and if
you think it says that somewhere, I'd like a pointer to where.  It
would need to be fixed if it said that, but as far as I can tell it
does not.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Jun 2011 08:51:48 -0400

>would need to be fixed if it said that, but as far as I can tell it

I believe the opposite.

 From the abstract:

    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.

Seeing these two sentences alone tells me that this document is 
setting up a registry and is setting up something to be compliant to 
the registry.

Bolstering my confusion is comments from the editor/Scott in a recent 
message (granted this is not in the draft):

"This doc doesn't change that at all.  You can still implement 
whatever you want, just not claim conformance to this doc."

Is the document an applicability statement to which software can 
conform, or is it a definition of a registry?

>RRTYPE for DNAME or DNSKEY.  In the same way, the registry of these

Why did you use the word "but" in there?  I can't make sense out of 
that paragraph, especially the second sentence.

Change happens, and the registry has to keep up to be relevant.  A 
software version is written to a static set of requirements (like an 
RFC).  Software (referring to the process of producing a series of 
versions) can be said to be compliant to a registry in the sense that 
the latest version reflects what is in a registry.

That might give a hint of why I find this draft's mission confusing. 
And why I really think it is a bad idea to codify recommendations to 
implement in a registry, which is what I read in this document.

---

From: Scott Rose <[email-masked]>
Date: Thu, 2 Jun 2011 14:10:29 -0400

>> would need to be fixed if it said that, but as far as I can tell it

Then perhaps a wording change?  It seems that it is confusion over the
language rather than the purpose.

 Scott

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Jun 2011 14:31:55 -0400

>language rather than the purpose.

A wording change is probably needed, but I can't suggest one because 
I can't determine what the goal is from what's currently written.  I 
know that sounds like a cheap shot, but I'm definitely not getting 
something here.

E.g., I'm assuming the document is suggesting that the IANA registry 
have the new column and that is my main complaint.  (That it 
shouldn't.)  If the matrix with the compliance column only appears in 
the document, while the IANA registry omits the column, I have no 
complaint.  Perhaps IANA lists the document as a reference at the end 
of the matrix, but the registry contents itself doesn't hold 
"recommendations."

Does that make sense?