Only sort of. In this case, the downgrade path is obvious, you
ignore the TLS flag and send the message along.
Not quite. Jim suggests minimal replies, I'd probably want to
at least see non-return of content as a matter of principle.
Those downgrade paths, which not as obvious or trivial as just
ignoring the flag, do prevent exposing a lot of the information
the sender was presumably trying to protect.
I meant obvious as in what people will do as opposed to what matches
the semantics of some threat model. If you have an EAI message with
a UTF-8 address, handing that to a non-EAI mail server is unlikely
to do anything useful. If you have a tls-only message, handing it
to a non-tls-only mail server is likely to get it delivered, albeit
without the TLS coverage and perhaps (lacking DNSSEC) to the wrong
place but that could happen anyway.
(i) Let the correct MX records come back from the DNS query
(ii) Let the IP addresses associated with those MX records
come back correctly, whether as additional information or in a
separate query-response transaction. Up to this point, DNSSEC
would be happy.
(iii) Intercept the target IP address and direct the traffic
to a compromised system.
Unless I've missed something, 7672 doesn't help.
With RFC 7672 the MX and A/AAAA records are signed so you know you
have the right IP address. There's also a signed TLSA record for the
MX, e.g.
_25._tcp.mailserver.example.com IN TLSA blah
If the mail server you contact doesn't present a certificate that
matches the TLSA record, you know you have problems.
By my reading of 7672, if a domain goes to the trouble of publishing
the signed MX, A, and TLSA, you should believe it and decline to
deliver mail if you don't get the right cert. This is basically the
reverse side of Jim's proposal, the recipient asserts that it does TLS
rather than the sender asserting that it wants TLS.
R's,
John
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp