On Thu, May 21, 2020 at 11:09:39PM -0400, Viktor Dukhovni wrote:
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.
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.
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.
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.
Indeed, that's a really good point. This flakiness of client implementation probably makes such a setup a non-starter.
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.
This would still work with the opposite priority order: TLSA for the domain named in the MX taking precedence, with fallback to TLSA for the fully-resolved CNAME if there is no TLSA record for the former and the full CNAME chain is authenticated.
Bottom-line, my take is you're grasping at straws.
I don't see how that's an apt description of a question about a possible flaw in the security design.
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.
Can you point me to a description of what is on-topic here? Even if this is not the right forum to make change, it seems like a reasonable forum to gauge opinion on the topic from people actually using DANE with SMTP and determine if or how approaching it in another forum (IETF) might be appropriate.
Rich