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?
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf