On Wed, Jun 1, 2011 at 11:03 AM, Edward Lewis
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
<draft-ietf-dnsext-dnssec-registry-fixes-08.txt> as a Proposed Standard
As someone that would implement against this document, I find its role
The title is
# Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA
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
Technically redefining if you want to split hairs.
I mention this because of the following text in the Introduction:
# This document replaces the original list with a new table that includes
# 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
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
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.
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?
dnsext mailing list
Ietf mailing list