> On Jan 8, 2019, at 9:11 PM, Peter Gutmann <[email protected]> wrote:
>
>> https://github.com/danefail/list :-(
>
> Woah, that's taking a DNSSEC mechanism back to the state of HOSTS.TXT from the
> 1980s. Once dane_fail_list.dat gets too big to be hand-edited, will someone
> create a global distributed database that can be queried for entries? You
> could call it the DANE Nonfunctionality Selector, or DNS.
The reason this exists is that today only a minority of senders check DANE TLSA
records (none of the really big ones like Google, Microsoft, Yahoo, ...), and
so some of the vanity domain hobbyists who turn on DANE may not realize they've
messed up.
This is a stop-gap measure until botching cert rollover has a sufficiently
dramatic impact to make the list redundant. Anyone who still wants to receive
email will need to implement a robust rollover process and monitoring, or
outsource hosting of their DANE domain to professionals.
Another reason for the list, is that tools like "certbot" do cert rollover
blissfully unaware that they may breaking the mail server's TLSA records,
and indeed a large fraction of the listed domains are Let's Encrypt users.
This is slated to change. I'm in conversation with the maintainers of
certbot, and should become DANE SMTP aware in the not too distant future.
If there are other popular ACME clients that need to be improved, please
ask the maintainers to get in touch with me.
The list will not be maintained at scale. There are 777k DANE domains,
of which ~300 are broken. A problem rate < 0.05% is not at all bad.
Best practices around cert rollover are not yet well understood by users
who find some random HOWTO on the internet and implement that. I would
hope that over time, better HOWTO guides will be nearer the top of Web
search results.
--
Viktor.
P.S. If any of the large providers reading this are not yet getting ready
to pilot DANE outbound, please do make plans. What would be especially
helpful is well publicized policies to enforce and not whitelist except
in large-scale emergencies where a similarly large peer screws up, and
queueing a billion messages would not be viable. This is not different
from essentially similar risks with MTA-STS.
Otherwise, giving users the ability to opt-out per-message (along the
lines of REQUIRETLS=NO) should be sufficient, if coupled with reasonably
timely delay notices.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
