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

Kristijonas Lukas Bukauskas <kr@n0.lt> Thu, 01 April 2021 02:27 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 08BE63A0EF0 for <ietf-smtp@ietfa.amsl.com>; Wed, 31 Mar 2021 19:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=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 m7XuPjGFmDSI for <ietf-smtp@ietfa.amsl.com>; Wed, 31 Mar 2021 19:27:33 -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 C7D373A0E9E for <ietf-smtp@ietf.org>; Wed, 31 Mar 2021 19:27:33 -0700 (PDT)
Received: from webmail.n0.lt (localhost.localdomain [IPv6:::1]) by ixion.n0.lt (Postfix) with ESMTPSA id AB1A9FC528; Thu, 1 Apr 2021 02:27:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=n0.lt; s=default; t=1617244046; bh=9SV9iF4KKZ4enbkQWkUWsfIIP8lzVWEUQ5WcnboEGLw=; h=From:To:Subject; b=A9Bbr194Oe9rO8YFZkzLwTskC0unEsVRJBZjaQyLc63eiZZlQXZAQU0YjarK2BQQ6 RNq0w8XdsMIXcwEKR1+3sKWWuIwJWoX4c1jzUmAWTN1bjg9DOw5nEpacvCAIFdegMy P0osY4vTKLjaDSA+BhneY69Fid1uk/peWx2a1FIw=
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: Thu, 01 Apr 2021 05:27:26 +0300
From: Kristijonas Lukas Bukauskas <kr@n0.lt>
To: John R Levine <johnl@taugh.com>
Cc: ietf-smtp@ietf.org
In-Reply-To: <b2acacaa-5bed-e332-1855-6ef0183cf42@taugh.com>
References: <20210401003023.713A871BE253@ary.qy> <d8768a088e2e9b73682e3d9bdbb372d9@n0.lt> <b2acacaa-5bed-e332-1855-6ef0183cf42@taugh.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <464756802f3425cb53c3be6392af4390@n0.lt>
X-Sender: kr@n0.lt
Content-Type: multipart/alternative; boundary="=_adc4ddb401db9914fa2770a5d3c8e71e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/lBDvwttQy7yzGCg5foD1rL-XgN4>
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: Thu, 01 Apr 2021 02:27:38 -0000

On 2021-04-01 04:41, John R Levine wrote:

> IETF standards tell you what to do to interoperate.  They generally
> don't tell you what to do when some part of a system doesn't follow
> the spec.

Thank you for your clarification.

>> By the way, from the last TLSRPT:
>> 
>> {"organization-name":"Microsoft 
>> Corporation","date-range":{"start-datetime":"2021-03-30T00:00:00Z","end-datetime":"2021-03-30T23:59:59Z"},"contact-info":"tlsrpt-noreply@microsoft.com","report-id":"132616914860181612+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":492},"failure-details":[{"result-type":"certificate-host-mismatch","failed-session-count":492}]}]}
>> Do they complain about the certificate which includes both n0.lt and 
>> *.n0.lt anyways?
> 
> Even without the CNAME error, why would it do that?  The cert matches
> the name of the MX.

So certificate-host-mismatch here should be understood that EITHER §4.1 
[1] (MX Host Validation) OR §4.2 [2] (Recipient MTA Certificate 
Validation) failed and not that, according to the report, the 
certificate hostname mismatched? Or what exactly?

--
Regards,
Kristijonas

Links:
------
[1] https://tools.ietf.org/html/rfc8461#section-4.1
[2] https://tools.ietf.org/html/rfc8461#section-4.2