Hi, Thanks for your questions, please see inline some clarifications.
Yours, Daniel On Fri, Dec 25, 2020 at 3:27 PM Paul Hoffman <paul.hoff...@icann.org> wrote: > 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? > <mglt> If I understand clearly the comment, it seems to say that TLS ( for example ) is using RFC Required and that DNSSEC should do the same. Quickly going through RFC 8447, I cannot find "RFC Required", so I am wondering if you have a specific registry in mind. As far as I can see, the TLS cipher suite registry requires Standard Action to set Recommended to "Y" and Specification Required otherwise. As a result, leaving it to Standard Action seems better aligned with what TLS does for "Recommended". My motivation for not lowering the requirement is based on the specificities of DNS, that is the DNS is a system handles a global shared resource - I think that is what I was trying to say in my first sentence. I am not aware of shared resources handled by the protocols you mentioned. DNS is part of the Internet architecture and an interoperability issue with DNS is an Internet infrastructure concern. A resolver not resolving .example affects all its worldwide clients willing to connect to any host in .example. An interoperability issue associated with the other security protocols being mentioned is an issue between one sender and one receiver. This seems to me less than an issue for the Internet. Olafur comes with additional differences between DNSSEC and other security protocols. </mglt> > > > 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. > > <mglt> If I understand your comment you seem to say that interoperability is overall provided by the DNSSEC developers as opposed to the IETF. In particular, developers will take the responsibility to make sure they all pick the same subset of crypto to ensure interoperability. If that is correct, it seems hard to explain that a resolver will not resolve some domains, and believe this is the role of the IETF instead is to provide such guidance. </mglt> > > 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. > > <mglt> My comment was that the specificities of DNS make code point assignment not only technical but potentially raise some policy issues. It seems important to be well aware of this and - in my opinion - avoid taking that path. Your comment seems to say that GOST is a Standard for DNSSEC which is unfair as this is not the case for other protocols and that GOST is only of interest by some specific countries. As mentioned earlier, DNSSEC has its own specificites that makes it different from other protocols. Typically, your comment seems to say that the use of GOST will be limited to the boundaries of a subset of countries. I think this is misleading as this is, in fact, used by anyone (worldwide) willing to access a web site associated with those countries/communities (under .ru, among others). I do see this as a fragmentation and believe we should avoid this as much as it is possible. More specifically, I expect that resolvers will have to implement anything that is used, which - again in my opinion - makes the requirement for anything non standard useless. </mglt> > > 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? > > <mglt> Looking at the call for adoption of RF6014 [1] this seems a legitimate question. On my side, I had not reviewed RFC 6014 but would have probably come with similar comments if the call for adoption would have been today. [1] https://mailarchive.ietf.org/arch/browse/dnsext/?q=dnssec-alg -allocation&gbt=1 </mglt> > --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
