On Dec 24, 2020, at 10:28 AM, Daniel Migault <mglt.i...@gmail.com> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
