RFC7672 2.2.2 "Secure CNAME" considered harmful?

[Rich Felker]

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 at 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.

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