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

Kristijonas Lukas Bukauskas <kr@n0.lt> Fri, 02 April 2021 20:50 UTC

Return-Path: <kr@n0.lt>
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 B6A903A238E for <ietf-smtp@ietfa.amsl.com>; Fri, 2 Apr 2021 13:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=n0.lt
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 Ynsk4mdUTibt for <ietf-smtp@ietfa.amsl.com>; Fri, 2 Apr 2021 13:50:09 -0700 (PDT)
Received: from ixion.n0.lt (ixion.n0.lt [188.166.32.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8EA03A236C for <ietf-smtp@ietf.org>; Fri, 2 Apr 2021 13:50:07 -0700 (PDT)
Received: from webmail.n0.lt (localhost.localdomain [IPv6:::1]) by ixion.n0.lt (Postfix) with ESMTPSA id A60D1FC440 for <ietf-smtp@ietf.org>; Fri, 2 Apr 2021 20:50:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=n0.lt; s=default; t=1617396604; bh=6cSDmSugnjErG7qjcooIjP7BAoewAvbEIRGWkuTI4gU=; h=From:To:Subject; b=T1/gAiDoTcLmIBBtZj2hQTFfzHIHYk2+gVblr5TnHeauHupgATsUQrZ/QnJZUo7eQ hoL+Hz4G4qX4be4DH1DTDwtMVnTo4QCh6trCmRFEx8TiAkfmu3qpN4rWUh73aUaP2G sh1dIlmRFLMwdreLnH20KkINgp5m6EbuDYuGpxSI=
Authentication-Results: ixion; spf=pass (sender IP is ::1) smtp.mailfrom=kr@n0.lt smtp.helo=webmail.n0.lt
Received-SPF: pass (ixion: connection is authenticated)
MIME-Version: 1.0
Date: Fri, 02 Apr 2021 23:50:04 +0300
From: Kristijonas Lukas Bukauskas <kr@n0.lt>
To: ietf-smtp@ietf.org
In-Reply-To: <YGdoXbtlHMhiGxaw@straasha.imrryr.org>
References: <59a4ba6c024e3cdc2c10dc6edc673ef7@n0.lt> <606733B6.3080609@isdg.net> <1fef5201d846d503151e4e63fda10e97@n0.lt> <YGdoXbtlHMhiGxaw@straasha.imrryr.org>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <72bb746bfe938835e1c6d7f58792e668@n0.lt>
X-Sender: kr@n0.lt
Content-Type: multipart/alternative; boundary="=_b649f937fd345f97e7a92701abb1fcde"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/_VyeI4ltaGDV9xy8GTQjMbcQ0FA>
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 20:50:18 -0000

On 2021-04-02 21:54, Viktor Dukhovni wrote:

> 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

So that's the failed MX Host Validation, as described in [RFC8461], 
section 4.1, that sending MTA seems to claim to be the problem. Correct?

> A receiving candidate MX host is valid according to an applied MTA-
> STS Policy if the *MX record name* matches one or more of the "mx"
> fields in the applied policy.  Matching is identical to the rules
> given in [RFC6125], with the restriction that the wildcard character
> '*' may only be used to match the entire left-most label in the
> presented identifier.  Thus, the mx pattern "*.example.com" matches
> "mail.example.com" but not "example.com" or "foo.bar.example.com".

If so, what error should the reporter use, as per [RFC8460], in an 
aggregated TLS report?

validation-failure?

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

Will do, immediately after the sending MTA finishes their testing (a few 
support teams at the sending MTA still work on my support tickets).

Please accept my deepest thanks for your professionalism and guidance.

--
Regards,
Kristijonas