[dns-operations] Support for ED25519/ED448 DS records by OpenSRS

[Tony Finch]

Florian Weimer <fw at deneb.enyo.de> wrote:
>
> The registry signs the DS RRset with its own key.  It's good practice
> to apply as many checks as possible when signing data supplied by
> untrusted parties.  Having to show the DNSKEY record for a DS record
> makes sure the embedded hash in the DS record is genuine, which
> prevents all known evil twin attacks on cryptographic signature
> schemes.

Very few TLDs receive DNSKEY records from their registrants, so they
aren't in a position to make this check.

(TLDs shouldn't restrict DS keys to published DNSKEY records because
that prevents double-DS KSK rollovers. CDNSKEY records avoid this problem
but they are not published as routinely as they ideally would be.)

> SHA-256 is not publicly known to be broken as of today, of course, but
> if that changes, such evil twin attacks are likely the first ones to
> arrive (see MD5 and SHA-1).  DS data checking looks like a reasonable
> way to increase the safety margin.

Yes, but there are simpler ways for a TLD to protect itself than by
regenerating the DS hash: just check that the DS digest type is known and
the digest is the correct length for the digest type. There's no need to
check the DNSKEY algorithm or the contents of the digest.

Hash collision attacks need at least a couple of input blocks to work.
(For instance, the SHA-1 input block size is 128 bytes and a SHAMBLES
collision needs 588 bytes.) This is generally bigger than the hash output
size (20 bytes for SHA-1, 32 bytes for SHA-256) so a correctly-sized DS
record is too small to use for a signature collision attack.

https://tools.ietf.org/html/draft-fanf-dnsop-sha-ll-not-00#section-5.5

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
individual and social justice