There's a reason that DANE requires DNSSEC. DNS responses are easily
faked by an attacker using a variety of means. From my reading of your
proposal, it also requires DNSSEC, though you don't word it that
strongly. If an MX record with target smtps- or starttls- isn't signed
using DNSSEC, it's not clear that the client should trust the smtps- or
starttls- prefix, and that the client should drop mail that can't be
relayed that way. At the very least an analysis is needed that shows
that the threats presented by faked DNS responses is no worse with
smtps- or starttls- records than with ordinary MX records. (Taken by
itself the threat of a DoS attack using faked DNS responses seems to be
worse with your proposal, but IMO the analysis needs to consider the
overall spectrum of threats including the threat of eavesdropping on
unencrypted SMTP transmissions.)
Or maybe there's another way besides DNSSEC to assure the validity of
the DNS response. Maybe, for example, the SMTP client can rely on the
response as being valid if it uses DoT or DoH to do the query and the
server certificate is (a) valid and (b) matches the DNS name of the zone
being queried. (I suspect the real trick, just as with any use of TLS
on an outsourced server, is trusting the DoT or DoH hosting provider to
securely manage the server certificate. But at least this is not a new
problem.)
(Given that there are currently huge tussles over use of DoH,
recommending DoT might be less controversial.)
Regarding the use of IDNs, the easiest way to address this is to not use
IDNs as the targets of MX records - since users don't generally see the
MX records anyway. But another fix would be to have the "smtps" or
"starttls" tag be a separate DNS label rather than a prefix to another
label.
Keith
p.s. It is indeed unfortunate that DNSSEC is so hard to deploy. From my
perspective I haven't seen that governments are the problem though, but
rather lack of support from registrars, and/or perhaps that there's not
enough information provided to zone administrators as to how to do it.
More work is definitely needed in this area.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp