On Thu, May 21, 2020 at 09:21:41PM -0400, Rich Felker wrote:
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.
This is not the right forum for this topic. Likely dane@ietf.org may have been more appropriate.
1. In fact MX records are supposed to not be CNAMEs. So you should not, and generally would not operate the inbound MTA for a domain via a CNAME to dyn.com.
2. Despite the above, most MTAs do honour "CNAME-valued" MX records. And the majority of those cases, the CNAME points at an MX provider, not a DNS-resolution provider like dyn.
3. If your IP records CNAME into a zone managed by an untrusted party, they can make your A-records appear unsigned, and some implementations will not fall back to a CNAME query to check for DNSSEC in the MX host's zone. The fallback CNAME check is tricky, and I do not expect it to be consistently.
4. In most such cases, the CNAMEs in question are multiple names for the same MTA managed by its owner, or aliases to a provider managed mailserver. Not a mailserver for which just the IP record is outsourced to a third party.
In the actual cases in use, the users benefit from a single operator managing both the target IPs and the target TLSA records. They would otherwise have to be sure to publish additional CNAMEs from their TLSA qname to the provider's TLSA RRset. This is extra work they're likely to neglect.
For example 472 domains alias MX hosts to mail.kingsquare.nl.
Bottom-line, my take is you're grasping at straws.
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.comwhere dummy-insecure.example.com is a zone that's intentionally left unsigned, to break the chain of authenticated data.
Yes, though as I mentioned, this can also break DANE, and nobody is going to do this...
But it seems unrealistic to expect people to know to do this,
We're on the same page here.
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?
Wrong forum, and we disagree.