RFC7672 2.2.2 "Secure CNAME" considered harmful?

[Viktor Dukhovni]

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.

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.com
> 
> where 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.

-- 
    Viktor.