Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

[Frederico A C Neves <[e-mail]>]

On Fri, Mar 23, 2018 at 03:58:02PM +0000, Viktor Dukhovni wrote:
> On Thu, Mar 22, 2018 at 01:27:38PM -0400, Paul Wouters wrote:
> 
> > I think this text also needs an update:
> > 
> > 	RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones
> > 	deploying it are recommended to switch to ECDSAP256SHA256 as there is
> > 	an industry-wide trend to move to elliptic curve cryptography.
> > 
> > They should switch away from SHA1 as SHA1 is being deprecated industry
> > wide. Even if we recommend to move away from RSA (which I'm not sure if there
> > is consensus on) to ECC, I would like to move them to ED25519/ED448 over
> > the ECDSA* variants.
> 
> I think it is, unfortunately, much too early for such a move.  For
> example, on Unix systems the requisite OpenSSL 1.1.x libraries that
> provide the Edwards EC algorithms, are not yet out of beta!  It
> will be some years before Ed25519 and Ed448 can be expected to be
> widely supported by resolvers.  Therefore, I would still strongly
> recommend ECDSA, which is widely supported.
> 
> We should certainly encourage the implementation of Ed25519/Ed448
> in resolver and nameserver implementations, but it is much too
> early for adoption, beyond dual DS/KSKs one ECDSA and another
> Ed25519, with the client choosing whichever it prefers.  ZSKs should
> IMHO migrate to ECDSA for now to alleviate packet size issues.

This is exactly one of our, .br. reasonings for moving forward to EC
now.

Talking this conversation to the root, all this rollover hurdles would
be much smaller, if any. We could leave with a Double signing for a
long time. With ECDSAP256/Ed25519 the keyset would be much smaller
than the current one, aparently we're about to roll the zsk, ~ 1/4 of
the size. And the signature would be ~ 1/2 of the current single
RSA2048 size.

Fred