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 [email protected] 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.
Indeed, that's a really good point. This flakiness of client implementation probably makes such a setup a non-starter. > 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. 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
