RFC7672 2.2.2 "Secure CNAME" considered harmful?

[Rich Felker]

I've been reading RFC7672, in particular the part about TLSA lookup
for the "Secure CNAME" case. Not only can I not find a legitimate
reason to attempt to obtain a TLSA record for the fully-resolved CNAME
first; further, I've come up with a very plausible scenario where it's
actively harmful and allows an untrusted party to seize control of the
service.

Consider a service hosted on dynamic IP address. One way to do this
without needing one's own dynamic DNS infrastructure is with CNAMES.
If one owns example.com, one can make foo.example.com a CNAME pointing
to a hostname on an existing dynamic DNS provider, e.g.
example.dyn.com. Traditionally, prior to DNSSEC and DANE, this would
have allowed dyn.com to hijack the service by redirecting the A record
for example.dyn.com. However, if example.com is authenticated by
DNSSEC and has a TLSA record pinning a particular key for
foo.example.com, one would expect this hijacking no longer to be
possible -- if dyn.com redirected example.dyn.com, they would not have
the private key matching the TLSA record, and could not hijack any
traffic from clients performing DANE validation.

However, RFC7672 section 2.2.2 specifically overrides this expectation
for SMTP, and mandates that, if dyn.com is also authenticated, clients
attempt to obtain a TLSA record for example.dyn.com and give it
precedence over the one for foo.example.com. This reopens the
possibility of hijacking, and seems outright wrong.

I believe it can be mitigated by someone aware of the problem, with a
dummy intermediate insecure zone:

    foo.example.com CNAME foo.dummy-insecure.example.com
    foo.dummy-insecure.example.com CNAME example.dyn.com

where dummy-insecure.example.com is a zone that's intentionally left
unsigned, to break the chain of authenticated data.

But it seems unrealistic to expect people to know to do this, and
error-prone since subtly non-conforming clients may misinterpret the
broken chain of authenticated data as foo.example.com being insecure
and not subject to DANE at all.

Can anything be done about this? Is there a reason for the existence
of the "Secure CNAME" case that needs to be preserved, or is this
something that could be pushed for deprecation?