RFC7672 2.2.2 "Secure CNAME" considered harmful?

Viktor Dukhovni ietf-dane at dukhovni.org
Fri May 22 07:16:40 CEST 2020


On Thu, May 21, 2020 at 11:31:32PM -0400, Rich Felker wrote:

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

That could have been a possibility, as indeed would requiring the domain
owner to actively provision a CNAME from _25._tcp.<cname-owner> to
_25._tcp.<cname-target>.

I optimized for two considerations:

    1. Ease of deployment.  If your MX host provider (possibly after
       CNAME resolution) has TLSA records, you're done.

    2. Alignment of operational responsibility.  Whoever is operating
       the MX host is best positioned to keep correct TLSA RRs in place.

This meant preferring the TLSA RRs as close as possible to the actual
MX host domain.  Now you have a corner case where the MX host is really
in the origin domain, and only its IP address resolution is delegated.

I must admit this was not considered at the time, but that I am
considering it, I am not especially fond of the idea of switching
the order of precedence.

What I can say is that TLSA RRs after CNAME indirection are not
terribly common, and we could (at the cost of not supporting DANE
for a small fraction of users) drop the CNAME chasing, not because
of the dyn.com situation, but simply because it is complex, and
perhaps not worth the cost.

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

This is a very quiet list, mostly just my monthly posts, but
occasionally some operational topics.  Not much standards discussion
here.  It'd probably be just you and me, and we could do that off-list.

I could be misjuding who's here of course...

-- 
    Viktor.


More information about the dane-users mailing list