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

[Sam Varshavchik <[e-mail]>]

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.n0.lt. It is consistent with what we are seeing with production. 

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.

>> Selecting an MX target host is regulated in a different RFC, namely and  
>> 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.