[ Moderators note: Post was moderated, either because it was posted bya non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ]
No. This creates an unneccessary link between two unrelated DNSSEC parameters. The danger is that if someone finds an attack that takes advantage of NSEC3, zones may have to choose between being vulnerable to that attack while using good hash algorithms and protecting themselves from the NSEC3 attack while using poor hash algorithms. Not a fun choice.There is no such risk. Zones operators have a choice of whether to generate NSEC or NSEC3 chains. I can generate NSEC chains with algorithm 5 or 7. Both are equally secure. The fact that one could generate a NSEC3 chain is irrelevent as one would also have to get the signatures on the NSEC3 chain accepted for there to be a threat and if you can get that to happen it doesn't matter if we are using NSEC or NSEC3 because the whole kit and kaboodle is gone.
Mark successfully corrected me. (Thank you, Mark.)Given that, I have no objection to removing the aliases (with appropriate explanation, Andrew's option 1). However, for the purposes of expediency, I suggest we take Andrew's option 3 and leave this document as it is. It only uses two extra identifiers at the moment, which seems an acceptable loss.
-- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>