On Wed, Jun 1, 2011 at 11:03 AM, Edward Lewis <[email protected]> wrote:
> 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. > 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 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. > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dnsext >
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
