Hi, As the DNS is a global shared resource and its reliability is based on **all** pieces of software adhering a common standard, I am inclined to believe that new cryptographic algorithms introduced with anything less restrictive than "IETF Review" - such as "Specification Required" and "RFC Required" - does not sufficiently prevent altering the interoperability of the DNS. This is likely to result in the introduction of potentially weak - and unmanageable - cryptography, a fragmentation of the DNS name space, as well as the introduction of policy matters within the IETF. Typically, some code points will be qualified as **standard** while others will be **non-standard**. This may put the IETF in a position to define that the trust of community C1 in algorithm A1 is non-standard while the trust of community C2 in algorithm A2 is standard. I believe we should avoid this path. In addition, I also believe that "Standard Track" is the appropriated status. While a call for adoption of a cryptographic algorithm with a "Standard Track" asks pretty clearly the community on whether they are willing to see that algorithm being deployed. The same call for adoption with another status is less clear and people may not feel concerned which will make it harder to judge the consensus. It is also envisioned that calls for adoption will have an extra round of discussion over the status which I am not sure is necessary.
As a result, I am inclined to believe we should not adopt draft-hoffman-dnssec-iana-cons and we should re-evaluate RFC6014. Yours, Daniel On Fri, Dec 11, 2020 at 11:35 AM Paul Hoffman <paul.hoff...@icann.org> wrote: > On Dec 11, 2020, at 8:26 AM, Tim Wicinski <tjw.i...@gmail.com> wrote: > > > > > > > > This draft was present at IETF108 and IETF109. There was interest in > adopting this, but I do recall that implementors had some concerns about > this. However, there was enough interest in starting an adoption > > call on this. > > > > > > > > Because of the holiday, I'm going to run this call until the 31st, to > allow folks to discuss. > > > > This starts a Call for Adoption for: draft-hoffman-dnssec-iana-cons > > > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hoffman-dnssec-iana-cons/ > > > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > > > Please also indicate if you are willing to contribute text, review, etc. > > > > This call for adoption ends: 31 December 2020 > > I'd like to see this adopted by the WG so that the GOST document can > proceed forward. I'm also quite interested to hear input from developers > about how they feel affected by the different options for documentation of > algorithms for DNSSEC. > > --Paul Hoffman_______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Daniel Migault Ericsson
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
