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

From: Kristijonas Lukas Bukauskas <[email-masked]>
Date: Thu, 01 Apr 2021 00:44:43 +0300

Hello,

I'm having an affair with one of the vendors as a sending MTA, honoring 
MTA-STS (RFC 8461). Their response:

> * Our TDS validation shows MX lookup for n0.lt returns n0.lt instead of 
> mx.n0.lt. It is consistent with what we are seeing with production.
> 
> _remote server(451 4.4.8 MX hosts of 'n0.lt' failed MTA-STS 
> validation.)' 3/24/2021 3:36:19 PM - Server at n0.lt (0.0.0.0) returned 
> '450 4.4.317 Cannot connect to remote server [Message=451 4.4.8 MX 
> hosts of 'n0.lt' failed MTA-STS validation.] 
> [LastAttemptedServerName=n0.lt]_
> * We can confirm that customer is not RFC compliant with MX pointing to 
> a CNAME and we don't think it is worth to change the logic to 
> accommodate that.
> * Customer does have an easy fix on their side, just to modify their 
> STS Policy to include n0.lt as one of the supported MX record.

My objections:

> I'm familiar with a general prohibition, pursuant to RFC 2181 § 10.3 
> [1], for MX records to point to CNAMEs. Despite that, I do not believe 
> that it should affect MX host validation in accordance with RFC 8 
> [2]461 §4.1 [2] when selecting a target MX host, for the reasons of:
> 
> *
> 
> RFC 2181 is an RFC on Clarifications to the DNS Specification, not 
> SMTP.
> *
> 
> Selecting an MX target host is regulated in a different RFC, namely and 
> specifically in RFC 5321 §5.1 [3]:
> 
>> If MX records are present, but none of them are usable, this situation 
>> MUST be reported as an error.<...> When a domain name associated with 
>> an MX RR is looked up and the associated data field obtained, the data 
>> field of that response MUST contain a domain name. That domain name, 
>> when queried, MUST return at least one address record (e.g., A or AAAA 
>> RR) that gives the IP address of the SMTP server to which the message 
>> should be directed. Any other response, specifically including a value 
>> that will return a CNAME record when queried, lies outside the scope 
>> of this Standard. The prohibition on labels in the data that resolve 
>> to CNAMEs is discussed in more detail in RFC 2181, Section 10.3 [38]
> 
> *
> 
> Thus, the prohibition of CNAMEs is NOT an SMTP or MTA-STS issue. As per 
> the RFC 5321 §5.1, which is used to select an MX target host, pursuant 
> to RFC 8461 §4.1 (MX Host validation), vendors are NOT allowed to 
> choose a different host name (in my scenario, n0.lt instead of mx.n0.lt 
> which is found in MX record). The situation MUST be reported as an 
> error, if none of the found records are usuable. That MUST happened 
> even if the target domain has not deployed MTA-STS. And this doesn't 
> seem to be the case. When MTA-STS is not deployed, Microsoft, as a 
> sending MTA doesn't return any errors.
> *
> 
> No major providers (including, but not limited to Gmail) nor publicly 
> available MTA-STS tests (including, but not limited to My Email 
> Communications Security Assessment (MECSA) by European Commission's 
> Joint Research Center) doesn't select n0.lt instead of mx.n0.lt which 
> is found in MX record nor does it show any errors, suggesting my 
> interpretation of different RFCs is most likely correct.

As advised by one of the authors of RFC 8461, I'm reaching out to the 
IETF SMTP list for your opinions, namely if MTA-STS, in theory, should 
fail to validate if an MX points to a CNAME.

Any insights would be much appreciated and thanked in advance. :)

--
Regards,
Kristijonas

Links:
------
[1] https://tools.ietf.org/html/rfc2181#section-10.3
[2] https://tools.ietf.org/html/rfc8461#section-4.1
[3] https://tools.ietf.org/html/rfc5321#section-5.1

---

From: Sam Varshavchik <[email-masked]>
Date: Wed, 31 Mar 2021 20:07:36 -0400

Kristijonas Lukas Bukauskas writes:

> Hello,
>
> I'm having an affair with one of the vendors as a sending MTA, honoring MTA- 
> STS (RFC 8461). Their response:
>
>
>
>
>    • Our TDS validation shows MX lookup for n0.lt returns n0.lt instead of

MX lookup for n0.lt. returns mx.n0.lt.

n0.lt.			269	IN	MX	10 mx.n0.lt.

The CNAME comes from A and AAAA lookups on mx.n0.lt. That's my understanding  
of how DNS works. If you look up a record, and there's a CNAME for it, you  
get the CNAME then the record for the alias (if trusted, else the onus is  
on you to rerun the query). If you look up a record and it exists, you get  
it. Whether the name is another hostname, and that hostname has a CNAME  
alias, that's not the road that's been traveled, yet.

>> specifically in <URL:https://tools.ietf.org/html/rfc5321#section-5.1>RFC  
>> 5321 §5.1:

I don't see this as an MX selection issue but as an STS validation issue. My  
stack agrees that the STS policy is valid.

$ testmxlookup --dnssec n0.lt
Domain n0.lt:
STS: enforcing
Relay: mx.n0.lt, Priority: 10, Address: ::ffff:188.166.32.32 (DNSSEC)
Relay: mx.n0.lt, Priority: 10, Address: 2a03:b0c0:2:d0::d1b:a001 (DNSSEC)

CNAME here involves the resolution of the mx.n0.lt hostname. The n0.lt  
resolves to mx.n0.lt. Everything here passes my interpretation of STS  
verification rules.

> As advised by one of the authors of RFC 8461, I'm reaching out to the IETF  
> SMTP list for your opinions, namely if MTA-STS, in theory, should fail to  
> validate if an MX points to a CNAME. 

I see nothing in RFC 8461 that seems to disallow it. In fact, this statement  
seems rather unambiguous to me:

4.1.  MX Host Validation

   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],

The "MX" record here is:

n0.lt.			300	IN	MX	10 mx.n0.lt.

That's the DNS record.

And it squares up with the policy file. And the "Server Identify Check"  
portion in rfc6125 seems to prohibit using CNAME aliases for hostname  
validation:

2.4.  Server Identity Check

   During the TLS negotiation, the client MUST check its understanding
   of the server hostname against the server's identity as presented in
   the server Certificate message, in order to prevent man-in-the-middle
   attacks.  Matching is performed according to these rules:

   o  The client MUST use the server hostname it used to open the
      connection as the value to compare against the server name as
      expressed in the server certificate.  The client MUST NOT use any
      form of the server hostname derived from an insecure remote source
      (e.g., insecure DNS lookup).  CNAME canonicalization is not done.

This seems to be consistent with traditional certificate validation rules:

www.yahoo.com.		60	IN	CNAME	new-fp-shed.wg1.b.yahoo.com.

My browser is happy to load https://www.yahoo.com, and validate the  
certificate for the CN of www.yahoo.com, instead of this alphabet soup.

An alternative interpretation here would have the result of the STS policy  
file validating n0.lt, but a TLS connection will need to validate a  
certificate for mx.n0.lt. In this case it wouldn't matter, the same cert  
works for both, but that doesn't quite add together, for me.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 1 Apr 2021 11:09:18 +1100

You need properly read the quoted section that talks about MX target being a CNAME.
In particular this sentence from RFC 5321, section 5.1:

   Any other response, specifically including a value that will return a
   CNAME record when queried, lies outside the scope of this Standard.

In other words “It is your problem if the target of the MX refers to a CNAME
and things break."

The MX records for n0.lt are NOT RFC compliant.  The target points to a CNAME.

With regards to others delivering mail to, just because an implementation is
more liberal, it doesn’t make it correct.  It’s a absolute pain in the butt
when the 900lb gorillas don’t reject erroneous configurations as then everyone
else is under pressure to work with those configurations.  You get “But it works
with …”.

% dig n0.lt mx
;; BADCOOKIE, retrying.

; <<>> DiG 9.15.4] <<>> n0.lt mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48337
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 239ed73d712edd7d01000000606505ac5ca63d7a998dc694 (good)
;; QUESTION SECTION:
;n0.lt.				IN	MX

;; ANSWER SECTION:

;; Query time: 2009 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Apr 01 10:28:44 AEDT 2021
;; MSG SIZE  rcvd: 81

% dig mx.n0.lt
;; BADCOOKIE, retrying.

; <<>> DiG 9.15.4 <<>> mx.n0.lt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30179
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: e8e0c48edf143f7e01000000606505b6cad98ca2cff6ac04 (good)
;; QUESTION SECTION:
;mx.n0.lt.			IN	A

;; ANSWER SECTION:
mx.n0.lt.		290	IN	CNAME	n0.lt.
n0.lt.			300	IN	A	188.166.32.32

;; Query time: 224 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Apr 01 10:28:54 AEDT 2021
;; MSG SIZE  rcvd: 95

> On 1 Apr 2021, at 08:44, Kristijonas Lukas Bukauskas <kr=[email-masked]> wrote:
> 
> Hello,
> 
> I'm having an affair with one of the vendors as a sending MTA, honoring MTA-STS (RFC 8461). Their response:
> 
> 
> 	• Our TDS validation shows MX lookup for n0.lt returns n0.lt instead of mx.n0.lt. It is consistent with what we are seeing with production. 
> 
> remote server(451 4.4.8 MX hosts of 'n0.lt' failed MTA-STS validation.)' 3/24/2021 3:36:19 PM - Server at n0.lt (0.0.0.0) returned '450 4.4.317 Cannot connect to remote server [Message=451 4.4.8 MX hosts of 'n0.lt' failed MTA-STS validation.] [LastAttemptedServerName=n0.lt]
> 	• We can confirm that customer is not RFC compliant with MX pointing to a CNAME and we don't think it is worth to change the logic to accommodate that.
>   
> 	• Customer does have an easy fix on their side, just to modify their STS Policy to include n0.lt as one of the supported MX record.
> 
> 
> 
> 
> My objections:
> 
> 
> 
>> I'm familiar with a general prohibition, pursuant to RFC 2181 § 10.3, for MX records to point to CNAMEs. Despite that, I do not believe that it should affect MX host validation in accordance with RFC 8461 §4.1 when selecting a target MX host, for the reasons of:
>> 
>> 	• RFC 2181 is an RFC on Clarifications to the DNS Specification, not SMTP.
>> 
>> 	• Selecting an MX target host is regulated in a different RFC, namely and specifically in RFC 5321 §5.1:
>> 
>> 
>> 
>>> If MX records are present, but none of them are usable, this situation MUST be reported as an error.<...> When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or AAAA RR) that gives the IP address of the SMTP server to which the message should be directed. Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard. The prohibition on labels in the data that resolve to CNAMEs is discussed in more detail in RFC 2181, Section 10.3 [38]
>> 
>> 
>> 	• Thus, the prohibition of CNAMEs is NOT an SMTP or MTA-STS issue. As per the RFC 5321 §5.1, which is used to select an MX target host, pursuant to RFC 8461 §4.1 (MX Host validation), vendors are NOT allowed to choose a different host name (in my scenario, n0.lt instead of mx.n0.lt which is found in MX record). The situation MUST be reported as an error, if none of the found records are usuable. That MUST happened even if the target domain has not deployed MTA-STS. And this doesn’t seem to be the case. When MTA-STS is not deployed, Microsoft, as a sending MTA doesn’t return any errors.
>> 
>> 	• No major providers (including, but not limited to Gmail) nor publicly available MTA-STS tests (including, but not limited to My Email Communications Security Assessment (MECSA) by European Commission’s Joint Research Center) doesn’t select n0.lt instead of mx.n0.lt which is found in MX record nor does it show any errors, suggesting my interpretation of different RFCs is most likely correct.
>> 
> 
> 
> 
> 
> As advised by one of the authors of RFC 8461, I'm reaching out to the IETF SMTP list for your opinions, namely if MTA-STS, in theory, should fail to validate if an MX points to a CNAME.  
> 
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 31 Mar 2021 20:30:22 -0400

>The MX records for n0.lt are NOT RFC compliant.  The target points to a CNAME.

Quite right.

"Doctor, doctor, it hurts when I do this."

"So don't do that."

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 31 Mar 2021 21:03:30 -0400

> > mx.n0.lt. It is consistent with what we are seeing with production.

[ Congratulations by the way on your working DANE deployment:
    https://stats.dnssec-tools.org/explore/?n0.lt

    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 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
    _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

  I should perhaps mention that the first "2 1 1" record above, matching
  the "X3" CA is obsolete and should now be dropped:
    http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html ]

> > _remote server(451 4.4.8 MX hosts of 'n0.lt' failed MTA-STS validation.)'
> > 3/24/2021 3:36:19 PM - Server at n0.lt (0.0.0.0) returned 
> > '450 4.4.317 Cannot connect to remote server
> > [Message=451 4.4.8 MX hosts of 'n0.lt' failed MTA-STS validation.] 

Indeed their implementation is flawed.  They should either streadfastly
refuse to deliver email to all domains where the the MX is a CNAME, and
so outside the interoperability scope of RFC5321.  Or, if like most
MTAs, they're pragmatic and allow CNAMEs, the CNAME should not affect
the logical MX host name used with MTA-STS, just as would be the case
with web browsers, etc.

With MTA-STS, the CNAME is just an indirect means of finding the MX
host's address records, and given that is generally not securely
obtained (though DNSSEC-signed in your case).  It should not change
the sender's notion of the logical nexthop relay hostname.

However, all that said, 8461 is silent on CNAMEs in MX hostnames, and so
there is no definitive guidance on this question.  The above is just my
personal viewpoint, based on extrapolation from similar contexts and
some handwaving logic.

> > STS Policy to include n0.lt as one of the supported MX record.

An even better solution is to AVOID the CNAME, and publish the
underlying A/AAAA records directly for mx.n0.lt.  That would be
by far the most sensible approach, given that CNAME-valued MX
RRs lie outside the scope of interoperable behaviour defined
in RFC5321, and are comparatively rare.

Using a biased sample of 14,552,195 DNSSEC-signed domains, only 58,451
of them (0.4%) have CNAMEs for their MX records.

Another sample is ~102k domains reported in Google email transparency
reports over the past month.  These have a total of 240,182 MX records
of which 690 (or ~0.28%) resolve to CNAMEs.

So my best guess is that ~0.3% +/- 0.1% of MX records are CNAMEs.  As
noted by others, if this is causing you some issues, avoid use of
CNAMEs.

-- 
    Viktor.

---

From: Kristijonas Lukas Bukauskas <[email-masked]>
Date: Thu, 01 Apr 2021 04:14:29 +0300

> "Doctor, doctor, it hurts when I do this."

Thank you for your position on the subject. :)

I'm _not_ advocating for MXs to point to CNAMEs because that's 
prohibited. You're right they mustn't be used. My question was 
different. To rephrase it: if MTA-STS validation should fail solely 
based on that, and whether such behavior of a Sending MTA honoring 
MTA-STS would be in accordance with RFC 8461.

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":"[email-masked]","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?

My questions here are being of an aim to discuss and for interpretation 
of  RFC(s) [especially RFC 8461] purpose only. :)

--
Regards,
Kristijonas

---

From: "John Levine" <[email-masked]>
Date: 31 Mar 2021 21:44:07 -0400

>the logical MX host name used with MTA-STS, just as would be the case

It seems to me pragmatic to say "we think we understand what you think you're doing,
but it's still wrong."

R's,
John

---

From: Kristijonas Lukas Bukauskas <[email-masked]>
Date: Thu, 01 Apr 2021 05:27:26 +0300

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.

> 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