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

[Eric Rescorla <[e-mail]>]

On Wed, Dec 30, 2020 at 7:23 PM Paul Wouters <[e-mail]> wrote:

> On Dec 30, 2020, at 22:11, Daniel Migault <[e-mail]> 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.