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

Simon Arlott simon at arlott.org
Sat Feb 20 11:37:02 UTC 2021


On 19/02/2021 19:01, Florian Weimer wrote:
>> Supposedly it is to protect registrants from bad data but it would be
>> trivial to simply enter the wrong numbers in the individual component DS
>> record web forms that everyone is fond of.
> 
> 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.  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.

There is no technical reason why they need to restrict that number in
the DS record. It has the exact same representation for all values 0 to
255.

I can just as easily select the "private algorithm" option and then the
DS record won't work properly because it won't be recognised by anyone.

The chance of errors is much higher when a form asking for 4 separate
parts of the whole DS record is presented.

The only credible thing to check is that the length of the hash matches
the hash algorithm, which necessitates knowing all possible hash
algorithms.


It's also my zone, so the DS record matching the DNSKEY is irrelevant.
If there is a collision attack on the hash algorithm this will not
change anything because there can still only be one hash value for the
input data.

There's no requirement for the DNSKEY to be published before adding DS
records and having a DNSKEY does not prove ownership of the private key.

-- 
Simon Arlott



More information about the dns-operations mailing list