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

John C Klensin <john-ietf@jck.com> Sun, 04 April 2021 20:54 UTC

Return-Path: <john-ietf@jck.com>
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 939B53A19F7 for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Apr 2021 13:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 GCcFxAkzwoVf for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Apr 2021 13:54:50 -0700 (PDT)
Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD8B3A19F5 for <ietf-smtp@ietf.org>; Sun, 4 Apr 2021 13:54:50 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lT9kw-000CqB-2U; Sun, 04 Apr 2021 16:54:02 -0400
Date: Sun, 04 Apr 2021 16:53:42 -0400
From: John C Klensin <john-ietf@jck.com>
To: John R Levine <johnl@taugh.com>, Kristijonas Lukas Bukauskas <kr@n0.lt>
cc: ietf-smtp@ietf.org
Message-ID: <BE4982F24C6848D1624C4D1D@JcK-HP5>
In-Reply-To: <a232c63-bf8-2371-51e1-b64d119ad55d@taugh.com>
References: <20210402002416.1825171CC176@ary.qy> <70B5B7CCF6D64FBA195CCAA5@JcK-HP5> <e87c4a27cb86ec5b32f0539754c341f3@n0.lt> <a232c63-bf8-2371-51e1-b64d119ad55d@taugh.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/IddHQYPAHQqrRWs-W6BrO9Y4zSg>
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 20:54:55 -0000


--On Sunday, 04 April, 2021 14:17 -0400 John R Levine
<johnl@taugh.com> wrote:

> On Sun, 4 Apr 2021, Kristijonas Lukas Bukauskas wrote:
>> Shouldn't an MTA-STS validator do *exactly* what RFC8461,
>> section 4.1 says:
> 
> That's not how standards work.  If you follow the standard,
> you should be able to interoperate with other people that
> follow it.  If you don't, the results are unpredictable.  We
> don't try to anticipate every possible mistake both because it
> is a waste of time and because it is impossible. I suppose it
> would be nice if Microsoft sent a better error message but
> that's not a bug I can get very excited about.
> 
> You know that pointing your MX at a CNAME is a mistake, so
> it'll fail at random.  It's a somewhat common mistake, but
> it's still a mistake.  If it were me, I would fix it and move
> on.

Agreed and let me make two small additions:

(1) I agree enthusiastically with your earlier "doctor, it hurts
when I do this" comment and the response.  It is clear, as you
suggest above, that having an MX record pointing to a name
associated with a CNAME (or, for that matter, anything but an
address record) is going to fail with some systems.  How many,
which ones, and how the failures occur is unimportant (which is
almost exactly with 5321 says in standard-ese). 

(2) With regard to both the above and the note Kristijonas
posted a few minutes ago, if RFC 8461 says anything that appears
to contradict the above, it is a bug and those who care should
be generating errata or, better yet, working on an update.  8461
can --at least as long as it is consistent with other deployed
specs-- say anything it likes about certificates, where they
come from, and how they are validated.  But, it is can be read
as encouraging violation of 5321 in a specification that is
clearly about SMTP, that is bad news.

    john