Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

[Paul Hoffman <[e-mail]>]

On Dec 24, 2020, at 10:28 AM, Daniel Migault <[e-mail]> wrote:
> 
> 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.  

Why do you feel that DNSSEC has requirements stronger than other IETF security prot0cols such as TLS, IPsec, S/MIME, and so on? 

> 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.

How would that happen? The developers of DNSSEC signing and validating software are intelligent, thoughtful people.

> 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.

Exactly right. DNSOP has already done that by adopting the GOST standard, which is only of interest to Russia (and maybe a small number of other countries). GOST is a standard *only* for DNSSEC, not for the other IETF security standards, which seems quite out of balance.

> 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.

What has changed since DNSOP discussed and adopted RFC 6014 that would make us want to do that? 

--Paul Hoffman