Bad interaction with MTA-STS

[Valodim]

Hey folks

Host authentication via onionmx, from what I understand, hinges on the SRV record that points to the hidden service, with no TLS/PKI or DNSSEC. That's not a huge issue compared to typical regular SMTP, given that most hosts don't validate TLS certificates either, and connections can be trivially downgraded.

However, this does become an issue for hosts that use MTA-STS, which offers reliable PKI host authentication via strict verification policies, and some measure of downgrade resistance.

So on a host that respects onionmx and MTA-STS for outgoing e-mails, the onionmx SRV record suddenly becomes the weakest link for authentication of recipient hosts. For example, if some host already knows via MTA-STS that gmail.com can be strictly authenticated by PKI certificate, an attacker could spoof an onionmx SRV record, and circumvent the host authentication that would have happened otherwise.

Any thoughts on this? Perhaps there is a simple fix, or my analysis is wrong?

(context: I considered adding onionmx support to keys.openpgp.org)

[dkg]

fwiw, some domains that offer onionmx are secured by DNSSEC:

0 dkg@alice:~$ dig +dnssec -t srv _onion-mx._tcp.riseup.net
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 31589
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 4096 B; ext-rcode: NOERROR
;; PADDING: 230 B

;; QUESTION SECTION:
;; _onion-mx._tcp.riseup.net.		IN	SRV

;; ANSWER SECTION:
_onion-mx._tcp.riseup.net.	600	IN	SRV	0 5 25 wy6zk3pmcwiyhiao.onion.
_onion-mx._tcp.riseup.net.	600	IN	RRSIG	SRV 14 4 600 20191107172946 20191024155946 33676 riseup.net. MIJDq4ljczqbpfqo9jcra1bMYS0HT5ZZi1ARAVVSVh+1WrnRsTt6YFspm7JuuprSnIBHBF23/QwoAlZEIfn3izzuKxCGfjROEl7jb+x3tO4vyIIuscpiLvE/LA11m7p6

;; Received 468 B
;; Time 2019-10-24 14:09:13 EDT
;; From 199.58.81.218@853(TCP) in 177.6 ms
0 dkg@alice:~$ 

If you've got a validating DNSSEC resolver, you can avoid the gap that you describe.

[Valodim]

If you've got a validating DNSSEC resolver, you can avoid the gap that you describe.

Are you just assuming that a validating dnssec resolver that hard fails for missing dnssec records would be a viable option now or anytime soon? Or am I missing something, and your idea would work without that?

[dkg]

There is a distinction between the following three cases:

• a DNSSEC-signed zone that offers cryptographically-valid _onion-mx SRV records ("good")
• a DNSSEC-signed zone that offers _onion-mx SRV records that cannot be validated ("bad")
• a zone that is not DNSSEC-signed (one of its ancestor zones offers an NSEC/NSEC3/NSEC5 record that covers the DS for its child), which offers unsigned _onion-mx SRV records ("unsigned")

If your goal is secure mail delivery, then yes, a validating dnssec resolver that hard-fails in the "bad" case is probably acceptable for _onion-mx delivery.

Note that delivery to "unsigned" zones via unsigned _onion-mx SRV records remains vulnerable.

[link2xt]

Alternative solution would be to stop using SRV records and instead use https://mail.example.net/.well-known/onion-mx.txt URLs to lookup onion MX domains. onion-mx.txt would contain the same contents as SRV records, i.e. .onion domains sorted by priority.

This is the same mechanism as MTA-STS uses, so there is no need to cross-check against MTA-STS and make transport map daemon interact with policy daemon.