> In MX delivery without DNSSEC, if Eve injects an MX record:

>   gmail.com. IN MX 1 my-spy-agency.example.org.

> then using the hostname from DNS means that the client will happily go
> talk to my-spy-agency.example.org, using that as the SNI, and validating
> against that same domain, then present back an "all's good here boss"
> status, saying that it's happily confirmed the identity of gmail.com in
> validation.

> The SNI identity should match the identity to be validated, else there's
> no point doing any validation.  Having clients willing to send SNI which
> they're not willing to accept as a valid value for verification is
> broken.  Since the client can't a-priori know which is which (legitimate
> gmail.com server or Other), when using hostnames from insecure DNS, the
> client shouldn't send SNI unless and until it has an identity which it's
> willing to validate.

> If using DANE, or if using MTA-STS where the hostname from DNS has been
> vetted against the whitelist from MTA-STS first, then everything changes
> and SNI becomes important.

AFAIK this does not happen in MTA-STS, that is, at no time is the MX hostname
obtained from the DNS checked against the "mx" list from the MTA-STS policy.
Rather, the DNS-ID of the certificate returned by the server is checked against
the "mx" list from the MTA-STS policy. This means that the mx hostnames may not
align with the certificates.

If you believe otherwise, I'd appreciate a pointer to where in the
specification it says that MX hostnames are supposed to be checked against
the "mx" list.


mailop mailing list

Reply via email to