On Thu, Apr 03, 2025 at 10:22:17AM -0700, Wes Hardaker wrote:
> Florian Obser <florian+i...@narrans.de> writes:
>
> > > validating resolvers MAY by configured to continue to validate RRSIG
> >
> > nit: s/by/be/
>
> Thanks, fixed!
I'd like to suggest a change in section 4:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-must-not-sha1-05#section-4
Old:
Zone owners currently making use of SHA-1 based algorithms should
immediately switch to algorithms with stronger cryptographic algorithms,
such as those listed in the introduction.
New:
Zone owners currently making use of DNSSEC algorithms based on SHA-1
should immediately switch to DNSSEC algorithms based on stronger
cryptographic algorithms. At time of writing, for DS records the
most widely deployed and interoperable digest type is SHA-256(2)
(RFC 4509). For DNSKEY and RRSIG records the most widely deployed
and interoperable DNS security algorithms are ECDSAP256SHA256(13)
and RSASHA256(8). Though not yet as widely deployed, ED25519(15) is
broadly supported by resolvers and is also a viable choice.
Rationale: The introduction lists multiple algorithms that are neither
widely deployed, nor particularly widely supported, e.g. algorithm 14
(P-384) just results in needlessly larger payloads, and much slower
performance! For example, on my CPU:
sign/s verify/s
ecdsa (nistp256) 62271.1 19904.0
ecdsa (nistp384) 5044.6 2197.2
So recommending ECDSAP384SHA384(14) (one of the algorithms listed in the
introduction) is I think unwise. Similarly, IIRC Google's resolvers
don't even support ED448(16) (mentioned in the introduction). So again,
there are strong reasons to NOT choose that algorithm.
sign/s verify/s
EdDSA (Ed25519) 32199.6 11372.1
EdDSA (Ed448) 5718.1 5371.8
--
Viktor.
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
