search

benbucksch / autoconfig-spec

Mail autoconfig protocol allows email clients to automatically configure email accounts. This report creates the RFC to standardize the protocol within the IETF.
Other
4 stars 2 forks source link

Mention MTA-STS regarding MX record security considerations #3

Closed link2xt closed 6 months ago

link2xt commented 7 months ago

MTA-STS can be used to secure MX records, e.g. https://mta-sts.gmail.com/.well-known/mta-sts.txt contains mx records that are allowed to be in DNS.

This could be mentioned in relation to https://github.com/benbucksch/autoconfig-spec/commit/335bd87bba671052a44ac7d1dfad69cde76f5210

cketti commented 6 months ago

Can you explain how MTA-STS would help in the context of autoconfig?

link2xt commented 6 months ago

Current draft describes MX record fallback: https://github.com/benbucksch/autoconfig-spec/blob/fdc206eb2c02eab22b5d167eb6b7da07b4591f83/draft-autoconfig-1.md#mx

And in security considerations it says that relying on DNS is not secure: https://github.com/benbucksch/autoconfig-spec/blob/fdc206eb2c02eab22b5d167eb6b7da07b4591f83/draft-autoconfig-1.md#dns

Unlike HTTPS connection to retrieve autoconfig XML, MX records can be easily spoofed if they are requested by a client device via malicious Wi-Fi hotspot. Let's say the client requests MX records for gmail.com, it will normally get gmail-smtp-in.l.google.com., alt1.gmail-smtp-in.l.google.com., ..., alt4.gmail-smtp-in.l.google.com..

In this case google.com may be a malicious domain controlled by an attacker. But we can retrieve https://mta-sts.gmail.com/.well-known/mta-sts.txt and check the lines which come from gmail.com HTTPS host confirming that these MX records are not spoofed:

mx: gmail-smtp-in.l.google.com
mx: *.gmail-smtp-in.l.google.com
link2xt commented 6 months ago

The other option would be to reduce the scope of the spec, describe how autoconfig over HTTPS works and not move the description of insecure alternatives (SRV, retrieving autoconfig XML over HTTP, MX records etc.) somewhere else.

benbucksch commented 6 months ago

@link2xt The MX lookup is necessary to get decent detection rates. They need to stay in the spec. If we cannot rely on DNS, then our detection rates are very low.

The spec describes multiple ways and factors to mitigate this risk.

benbucksch commented 6 months ago

@link2xt @cketti

  1. How widely is MTA-STS supported?

MX records can be easily spoofed if they are requested by a client device via malicious Wi-Fi hotspot

  1. The spec already mentions this risk and recommends to use DNS over HTTPS (DoH) to verify the MX records, to avoid such scenarios. What does MTA-STS add on top of that?
link2xt commented 6 months ago
  1. How widely is MTA-STS supported?

I have no statistics at hand, but some list I collected looking into it some time ago, seems it is supported by many major providers:

You can also find a lot of domains supporting it at https://www.google.com/search?q=inurl%3Amta-sts.txt

Google Workspace supports it, but AFAIK does not require to setup mta-sts subdomain domain, it is optional: https://support.google.com/a/answer/9261504

2. The spec already mentions this risk and recommends to use DNS over HTTPS (DoH) to verify the MX records, to avoid such scenarios. What does MTA-STS add on top of that?

In Delta Chat we are not going to use DoH because we don't want any dependency on central servers such as Google/Cloudflare DoH in the client. The only exception is the 8.8.8.8 fallback due to unresolved problems with DNS resolution in the dependency, map tiles in experimental location streaming feature and https://autoconfig.thunderbird.net/v1.1/ requests which we should probably just replace with an ISPDB snapshot preloaded into the binary.

Our current solution is to query MX with system DNS, but then only allow to configure Gmail this way. So Google Workspace domains work, but an attacker controlling malicious Wi-Fi hotspot has to be Google to make any use of MX response spoofing.

benbucksch commented 6 months ago

Delta Chat we are not going to use DoH because we don't want any dependency on central servers such as Google/Cloudflare DoH in the client

I understand why you don't want to give information to third parties, esp. Google and co.

To run the full autoconfig, you will need the ISPDB, so you have this point of centralization anyways. You could use a DoH server of your own, or on the domain/owner of the ISPDB.

How you validate the MX entry is your own choice.

Indeed, it's maybe a good idea to add the MTA-STS in the same section where I mention DoH, as an alternative.

mimi89999 commented 6 months ago

MTA-STS works similarly to HSTS. The other MTA first makes a DNS query and then caches the result.

Autoconfig will make the connection only once or very rarely, so there simply is no way to tell whether the server does support MTA STS.

mimi89999 commented 6 months ago

BTW, why is doing MX queries over DoH mentioned, but SRV queries were rejected completely?

benbucksch commented 6 months ago

https://mta-sts.gmx.com/.well-known/mta-sts.txt

This specific example is not really that helpful, because don't need the MX record to look up the ISP for gmx.com, because it's gmx.com. (And we have gmx.com in the ISPDB.) We need the MX specifically for domain hosters, and the customer domains typically do not have MTA-STS. Indeed, not even gmx.biz (which is a gmx.net domain) has it: https://mta-sts.gmx.biz/.well-known/mta-sts.txt gives "host not found". So, for exactly those cases where we need the MX lookup, MTA-STS does not work, in current deployments, and is unlikely to work in the future, due to the configuration overhead per customer domain. MTA-STS is exactly the same method as autoconfig, so if you set up MTA-STS, you might just as well also set up autoconfig.

I was about to add the following paragraph to section "DNS": " The MX server could be validated using MTA-STS, i.e. https://mta-sts.%EMAILDOMAIN%/.well-known/mta-sts.txt However, that is not widely deployed on customer domains, therefore limiting its usefulness. " But I really doubt it would help anything in practice to make that additional call. In exactly the cases where we need it, it's not deployed.

link2xt commented 6 months ago

BTW, why is doing MX queries over DoH mentioned, but SRV queries were rejected completely?

I would prefer not to add SRV because they are currently not supported by clients (at least Thunderbird, K-9 and Delta Chat). If they go into RFC, then some clients will support them and some not, so it is still better to just publish autoconfig XML, but complexity will be increased even more. Unless we have a list of existing providers which don't have autoconfig XML but have SRV records, adding this does not help.

benbucksch commented 6 months ago

DNS SRV:

BTW, why ... SRV queries were rejected completely?

That's offtopic here, and it's a FAQ, so I wrote #4 for that.

Unless we have a list of existing providers which don't have autoconfig XML but have SRV records, adding this does not help.

Exactly.

link2xt commented 6 months ago

But I really doubt it would help anything in practice to make that additional call. In exactly the cases where we need it, it's not deployed.

Let's close the issue then, at least for now.

The conclusion is that MX record lookup is optional and is intended for legacy setups which don't support autoconfig, so they are unlikely to support mta-sts as well. We better push them to support https://autoconfig.*.

benbucksch commented 6 months ago

MX record lookup is optional

Actually, the MX record lookup is important for the autoconfig protocol. To fully support the protocol, and to get decent detection rates, the DNS MX lookup is needed.

The result is: If you're concerned about DNS spoofing, you can use your own DoH server or that of the ISPDB to validate the results. The spec also mentions multiple other mitigations of different nature. The combination works reasonably well.

We better push them to support https://autoconfig.*.

Agreed. The -02 version of the spec has a section with recommendations for mail providers, both single domain providers and customer domain hosters.

link2xt commented 6 months ago

Actually, the MX record lookup is important for the autoconfig protocol. To fully support the protocol, and to get decent detection rates, the DNS MX lookup is needed.

In Delta Chat I think we are not going to support MX lookup and say that provider should provide autoconfig, add them to preloaded provider database or recommend users to switch to a different provider, e.g. not use their work/university email if it has this broken autoconfig setup, but use their other email or create a chatmail account just for chatting. But this usecase is different from mail clients which care about corporate email setups, e.g. Evolution, Outlook, Thunderbird etc.

you can use your own DoH server or that of the ISPDB to validate the results

We already have a built-in provider database, may at some point import Thunderbird ISPDB in there and stop requesting it as well.

benbucksch commented 6 months ago

That's of course up to you, yes. I understand that your usecase is different.

link2xt commented 6 months ago

That's of course up to you, yes. I understand that your usecase is different.

It would be nice to turn "If the previous mechanisms yield no result, the client may perform a DNS MX lookup on the email domain, and retrieve the MX server (incoming email server) for that domain." into a formal "MAY" so we can skip it but still be considered a proper implementation from IETF point of view.

benbucksch commented 6 months ago

It's intentionally mandatory for full spec support, because otherwise detection rates go down too much. See section 4, last paragraph. https://benbucksch.github.io/autoconfig-spec/draft-autoconfig-1.html#name-config-retrieval-for-mail-c