Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Eric Rescorla <[e-mail]>]

On Wed, Jun 17, 2020 at 8:51 PM Martin Thomson <[e-mail]> wrote:

> I agree with Olafur on this.  The reason we standardize is so that we can
> have a single - ideally very small - set of algorithms that are widely
> implemented.  Because you want every one of those algorithms in every
> implementation.
>
> In a system like the DNS, you can't really limit the people who might need
> to consume your signature, so the set of acceptable signing algorithms
> needs to be small.  Ideally you have just two: one that is established, and
> one that is new; or one using one technique and a backup using a different
> technique.
>
> TLS has mostly gotten this part right.  We're much closer to the point of
> having just two in TLS 1.3.  There are a few algorithms that exist to
> address narrow application domains (IoT, *cough*), but at least you can
> make a case for TLS deployments in a closed environment.  For that case,
> TLS allows for codepoint allocation, but avoids an IETF recommendation for
> those algorithms.  I don't think that DNS needs that same capability;
> deciding based on whether algorithms are good for global system is the only
> relevant criterion.
>
> If we all agree that GOST is superior to RSA (it probably is) and EdDSA (I
> doubt it, but I don't have an opinion), then adoption to replace an
> existing algorithm would be fine.  That didn't happen last time, so that
> suggests it would be better for RFC 5933 to be deprecated entirely.
>

largely concur with MT and Olafur.

At a high level, additional algorithms create additional complexity
and interoperability issues. In some cases there are good reasons for
that (for instance, one algorithm is much faster than another),
however that does not appear to be the case here. In the past we were
often quite liberal about standardizing national algorithms but I
believe this was a mistake which created confusion about what
algorithms the IETF actually was encouraging people to use. In
addition to the factors that Martin notes, it created pressure on
implementations to add those algorithms.

I don't see any good argument for the IETF recommending that people
adopt this algorithm, which does not seem to be in any way clearly
superior to EdDSA and which would open the door to us recommending a
proliferation of other national algorithms which also don't seem to
have any real technical advantages. As MT says, the argument for
assigning a code point while not recommending the algorithm seems
weaker here because you want DNSSEC signed data to be universally
verifiable.

My preference would be to not publish this at all, but if it is to
be published, do so in a way that makes clear that the IETF is just
allocating the code point and does not recommend it.

-Ekr

>
>