On Wed, Dec 30, 2020 at 7:23 PM Paul Wouters <p...@nohats.ca> wrote: > On Dec 30, 2020, at 22:11, Daniel Migault <mglt.i...@gmail.com> wrote: > > > > > > <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". > > As previously explained in this thread, you cannot compare TLS with > DNSSEC. With TLS you can offer IETF algorithms along with a nation state > algo, and the client can pick what it prefers. > > For DNSSEC, the signed zone has already made all the decisions. A DNS > client cannot decide to use or not use its local national algo. > > Paul > > > 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 > > For those regimes who for instance are not allowed to trust RSA or > NIST/NSA based ECC curves, you prefer those zones use no DNSSEC at all > versus say GOST ? > > Because that’s what you are offering as the only choice now. >
Thanks for making the point so sharply, Paul. To be transparent about my priors, I think it would be better if people used one of the more typical IETF algorithms, which is to say ECDSA or EdDSA [0]. With that said, for whatever reason there are people who want to use some other set of algorithms and the IETF's ability to discourage them is limited. The IETF really has three main options: 1. Don't allocate a code point at all 2. Allocate the code point but in some manner that makes clear we don't endorse it (effectively what TLS does for algorithms like this) 3. Allocate the code point without comment My general sense is that (1) and (2) do to some extent discourage the use of these algorithms (with (1) being more effective than (1)) but (1) may discourage them *entirely*, so the likely result is that people who want to use them just squat on a code point (or worse, multiple code points!) and we lose those code points anyway, but potentially after some interop problems. It's for this reason that I think (2) is the best approach here. As a number of people have noted, DNSSEC is different from TLS, IPsec, etc. in that there's no real opportunity to negotiate. I don't think that this changes the basic calculation but it might make it worth investing more effort in discouraging people, both to prevent algorithms that we think people should avoid and to reduce sharding of the ecosystem if, for instance, some implementations opt not to do algorithm X. It might also make it worth spending more effort in helping people get good definitions of algorithm X even if we don't think they should use it (as opposed to with TLS where the response is mostly "go ahead and register, but don't bother us"). I'm skeptical that "RFC Required" would foster either one of these goals, but perhaps that's what Daniel is arguing? -Ekr [0] I think we should discourage RSA.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
