Lets look at this in pure security terms.

The purpose of a security scheme is to manage risk, what are the risks
to be managed here? One of the reasons this group has taken so long is
that the risks were never grounded in concrete use/abuse cases and so
feature triage was never performed.

From the risk management point of view there are some abuse cases where
the ability to insert records has absolutely no negative effect
whatsoever and others where the abuse cases are very important.

There are two parts to look at here, zone signer and the zone verifier

If we are looking at core DNS zone insertion is not meaningful since
anyone can obtain any domain they chose for the sum of $10 or less or
zero if they use a stolen card. An insertion attack is not a threat
unless and until measures are deployed that makes it harder to register
lookalike or cousin domains.

For core DNS deployment of NSEC3 is acceptable, deployment of the
original NXT is unacceptable and SO would probably be acceptable -
albeit now the work is mostly done for NSEC3.

For deployment at the network level record insertion is potentially a
major issue, particularly if the motive for deploying DNSSEC is to
enable secure deploment of DNS driven policy based security to address
deperimeterization such as I will be proposing in a few days. The
complexity of generating the link records is not a major concern.

From the zone verifier point of view the SO draft does not change
anything whatsoever. The decision to verify NSEC records of any type has
to be driven by the security needs of the application, not the standard.
A signature verifier can always decide to ignore the NSEC records just
as an application can always decide to ignore DNSSEC altogether.=20

The decision an application makes is driven by its security needs and
the decision it is going to take. For example if we have a device that
has the logic 'if there is a security chain and everything is OK then do
X, otherwise do nothing at all' there is no point in implementing NSEC
verification since there is no alternative action the device can take.
Clearly DoS is a potential problem in such a situation and has to be
handled somewhere but the device that has no access to reliable DNS is
not going to be able to do that.

So looking through the cases I don't see that considering SO is
necessary. Verifiers always have the option to do SO if they chose. SO
does not seem to meet the signer needs that are not already met by

The only real advantage I see to putting SO on the table would be to
remind people of the fact that any improvement on existing DNS security
is better than we are now. Crypto-perfectionism does not lead to
successful deployment.

to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.