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

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 02 April 2021 18:54 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 6A0253A14FF for <ietf-smtp@ietfa.amsl.com>; Fri, 2 Apr 2021 11:54:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 nfbxgNZwBD6G for <ietf-smtp@ietfa.amsl.com>; Fri, 2 Apr 2021 11:54:24 -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 F390A3A14FE for <ietf-smtp@ietf.org>; Fri, 2 Apr 2021 11:54:23 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id AB51CDB76C; Fri, 2 Apr 2021 14:54:21 -0400 (EDT)
Date: Fri, 2 Apr 2021 14:54:21 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf-smtp@ietf.org
Message-ID: <YGdoXbtlHMhiGxaw@straasha.imrryr.org>
Reply-To: ietf-smtp@ietf.org
References: <59a4ba6c024e3cdc2c10dc6edc673ef7@n0.lt> <606733B6.3080609@isdg.net> <1fef5201d846d503151e4e63fda10e97@n0.lt>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1fef5201d846d503151e4e63fda10e97@n0.lt>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/Sa8VvGaPIbRPWyGQ2QuEeFgx49c>
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: Fri, 02 Apr 2021 18:54:28 -0000

On Fri, Apr 02, 2021 at 07:00:05PM +0300, Kristijonas Lukas Bukauskas wrote:

> {
>   "organization-name": "Microsoft Corporation",
>   "date-range": {
>     "start-datetime": "2021-03-31T00:00:00Z",
>     "end-datetime": "2021-03-31T23:59:59Z"
>   },
>   "contact-info": "tlsrpt-noreply@microsoft.com".com",
>   "report-id": "132617776923269755+n0.lt",
>   "policies": [
>     {
>       "policy": {
>         "policy-type": "sts",
>         "policy-string": [
>           "version: STSv1",
>           "mode: enforce",
>           "mx: mx.n0.lt",
>           "max_age: 84600"
>         ],
>         "policy-domain": "n0.lt"
>       },
>       "summary": {
>         "total-successful-session-count": 0,
>         "total-failure-session-count": 36
>       },
>       "failure-details": [
>         {
>           "result-type": "certificate-host-mismatch",
>           "failed-session-count": 36
>         }
>       ]
>     }
>   ]
> }
>
> 
> Is this a correct error to return, even if with CNAME/MX? (SANs are 
> n0.lt and *.n0.lt in my cert.)

The error indicated is indeed misleading, since the problem appears
to rather be a mismatch between the CNAME-expanded MX hostname and
the "mx: " field of the MTA-STS policy.  The certificate matches
either name, so isn't plausibly the problem:

    mx.n0.lt. IN CNAME n0.lt.
    n0.lt. IN A 188.166.32.32

Mind you, I do think that the sender should (in due course) change their
MTA-STS implementation to process MX CNAMEs in a manner that does not
change the logical MX host that is compared against the STS policy.

Sure, given the RFC5321 language, and the relatively low impact, they
can choose to give the fix low priority, but inevitably this issue will
crop up from time to time, and it simpler to address it at some point
than to steadfastly point out that the receiving system is somewhat
outside the spec.

The reason to be lenient here, is that MTA-STS aside, RFC5321
notwithstanding, MTAs, including theirs, generally allow CNAMEs in the
MX record, and it is a nuisance if enabling MTA-STS, ... suddenly
breaks that, for non-obvious reasons.

However, as a receiving system, in the meantime, you can do yourself and
everyone else a favour by changing your DNS to avoid the CNAME.

Since you're also using DANE:

    n0.lt. IN MX 10 mx.n0.lt.
    mx.n0.lt. IN CNAME n0.lt.
    n0.lt. IN A 188.166.32.32
    n0.lt. IN AAAA 2a03:b0c0:2:d0::d1b:a001
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
    _25._tcp.mx.n0.lt. IN TLSA 3 1 1 d08c6f7395e84d2253d89f4c959ff87bf3c366752cbe96afe868be1322d84188

that would be either:

    n0.lt. IN MX 10 mx.n0.lt.
    mx.n0.lt. IN A 188.166.32.32
    mx.n0.lt. IN AAAA 2a03:b0c0:2:d0::d1b:a001
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
    _25._tcp.mx.n0.lt. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
    _25._tcp.mx.n0.lt. IN TLSA 3 1 1 d08c6f7395e84d2253d89f4c959ff87bf3c366752cbe96afe868be1322d84188

or alternatively:

    n0.lt. IN MX 10 n0.lt.
    n0.lt. IN A 188.166.32.32
    n0.lt. IN AAAA 2a03:b0c0:2:d0::d1b:a001
    _25._tcp.n0.lt. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
    _25._tcp.n0.lt. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
    _25._tcp.n0.lt. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
    _25._tcp.n0.lt. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
    _25._tcp.n0.lt. IN TLSA 3 1 1 d08c6f7395e84d2253d89f4c959ff87bf3c366752cbe96afe868be1322d84188

You can use CNAMEs in TLSA RRs if you like:

    n0.lt. IN MX 10 n0.lt.
    n0.lt. IN A 188.166.32.32
    n0.lt. IN AAAA 2a03:b0c0:2:d0::d1b:a001
    _25._tcp.n0.lt. IN CNAME _25._dane.n0.lt.
    _25._dane.n0.lt. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
    _25._dane.n0.lt. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
    _25._dane.n0.lt. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
    _25._dane.n0.lt. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
    _25._dane.n0.lt. IN TLSA 3 1 1 d08c6f7395e84d2253d89f4c959ff87bf3c366752cbe96afe868be1322d84188

-- 
    Viktor.