Thanks Keith for the excellent insight.
You have made some excellent points. Yes, "a separate DNS label" is much
cleaner than using a prefix. Thanks for the suggestion.
You are right. My solution needs DNSSEC to work properly. Honestly, I have
no idea about the future of DNSSEC. Especially when big companies are
against DNSSEC. Maybe another standard like DNSCurve would replace DNSSEC
in the future. So the future of DNSSEC is still questionable.
When I prepared my proposal, my intention was focusing only on the
"signaling" part. That's because these MX records can also provided by
third party mail hosting like Google. Besides I don't want to force a
complicated technology just to support my solution. In any case, a plain
prefix-based MX record is pointless without DNSSEC or its alternatives.
Clients should treat a plain prefix-based MX record just like any other MX
record until DNSSEC support available for that domain. I think DNS Over TLS
is a good suggestion. If we can't go with the DNSSEC route, the we should
go with DoT route as you suggested.
Thanks
On Sun, Oct 6, 2019 at 5:43 PM Keith Moore
<moore(_at_)network-heretics(_dot_)com>
wrote:
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
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp