On Wed, Jun 1, 2011 at 11:03 AM, Edward Lewis <Ed.Lewis@xxxxxxxxxxx> wrote:
At 8:22 -0700 5/26/11, The IESG wrote:As someone that would implement against this document, I find its role confusing.
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 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.
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 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 toThe 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.
# measure compliance to this RFC only.
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
Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?
_______________________________________________
dnsext mailing list
dnsext@xxxxxxxx
https://www.ietf.org/mailman/listinfo/dnsext
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf