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.
pgpsPsF3R4_W1.pgp
Description: PGP signature
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp