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?