Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 04 April 2021 16:40 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9363A0FD9 for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Apr 2021 09:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRaq4bTnKc1Q for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Apr 2021 09:40:31 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB66F3A0FC5 for <ietf-smtp@ietf.org>; Sun, 4 Apr 2021 09:40:31 -0700 (PDT)
Received: from [192.168.1.177] (unknown [192.168.1.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 21326DC512 for <ietf-smtp@ietf.org>; Sun, 4 Apr 2021 12:40:30 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <cone.1617551902.793499.18351.1004@monster.email-scan.com>
Date: Sun, 4 Apr 2021 12:40:27 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: ietf-smtp@ietf.org
Message-Id: <D677803F-5C65-419D-887F-FE5024A6FA71@dukhovni.org>
References: <20210402002416.1825171CC176@ary.qy> <70B5B7CCF6D64FBA195CCAA5@JcK-HP5> <cone.1617551902.793499.18351.1004@monster.email-scan.com>
To: ietf-smtp@ietf.org
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/gZpfwWDuyo0fLfgszQhe9cgnjSc>
Subject: Re: [ietf-smtp] =?utf-8?q?MTS-STS_validation_when_MX_host_points_to_?= =?utf-8?q?a_CNAME=2C_violating__RFC_2181_=C2=A7_10=2E3?=
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Apr 2021 16:40:37 -0000

> On Apr 4, 2021, at 11:58 AM, Sam Varshavchik <mrsam@courier-mta.com> wrote:
> 
> The specification's audience is mostly SMTP implementations. But the onus on
> complying to this requirement is on the owners and operators who configure
> their domains. And in the context of setting up and installing their DNS
> records, there's nothing wrong with installing a CNAME for an MX target.

This is it in a nutshell.  MTAs in fact (continue to) support CNAME-valued
MX exchange hosts, and users don't expect to run into any issues.  So the
prohibition in 5321 is largely unexpected to them.

The fact that the overwhelming majority of domains have MX hosts that are
not CNAMEs is partly a result of concentration: a small number of MX hosts
serve a large number of domains, and partly the fact that MX indirection
entirely obviates the need for separate CNAME indirection:

 example.org. IN MX 0 mx.example.org.
 mx.example.org. IN CNAME smtp.provider.net.

    Why on earth not just:

 example.org. IN MX 0 smtp.provider.net.

And yet this through ignorance, fashion or oddity of tooling this is
marginally popular.  Complexity only sets in when implementations need
to choose reference identifiers for TLS, and perhaps don't think it
through carefully enough.  So in combination with MTA-STS and DANE,
CNAME handling gets a bit more error-prone.

So I think that users SHOULD avoid the CNAMEs, and yet MTAs should
do their best to work anyway.

-- 
	Viktor.