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, 02 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] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3
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", > "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.
- [ietf-smtp] MTS-STS validation when MX host point… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… Sam Varshavchik
- Re: [ietf-smtp] MTS-STS validation when MX host p… Mark Andrews
- Re: [ietf-smtp] MTS-STS validation when MX host p… John Levine
- Re: [ietf-smtp] MTA-STS validation when MX host p… Viktor Dukhovni
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTA-STS validation when MX host p… John Levine
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… John R Levine
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… Sam Varshavchik
- Re: [ietf-smtp] MTS-STS validation when MX host p… John Levine
- Re: [ietf-smtp] MTS-STS validation when MX host p… Hector Santos
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… Viktor Dukhovni
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… Viktor Dukhovni
- Re: [ietf-smtp] MTS-STS validation when MX host p… John C Klensin
- Re: [ietf-smtp] MTS-STS validation when MX host p… Sam Varshavchik
- Re: [ietf-smtp] MTS-STS validation when MX host p… Viktor Dukhovni
- Re: [ietf-smtp] CNAME considered harmful, was MTS… John R Levine
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… John R Levine
- Re: [ietf-smtp] MTS-STS validation when MX host p… Arnt Gulbrandsen
- Re: [ietf-smtp] CNAME considered harmful, was MTS… John C Klensin
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… John C Klensin
- Re: [ietf-smtp] MTS-STS validation when MX host p… Mark Andrews
- Re: [ietf-smtp] on liberality, was MTS-STS_valida… John Levine
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] on liberality, was MTS-STS_valida… Dave Crocker
- Re: [ietf-smtp] MTS-STS validation when MX host p… Sam Varshavchik
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… Bron Gondwana
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… Arnt Gulbrandsen
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas
- Re: [ietf-smtp] MTS-STS validation when MX host p… John C Klensin
- Re: [ietf-smtp] MTS-STS validation when MX host p… Kristijonas Lukas Bukauskas