[dane] Adoption data-point and operational considerations...

[Viktor Dukhovni <[e-mail]>]

[ In part WG-related, please see questions at the end... ]

Google's email transparency report in includes a last of mail
sending and receiving domains that are "large enough" to be included
in their stats.

    https://www.google.com/transparencyreport/saferemail/data/

Out of 17800 domains, 270 had DNSSEC-signed MX records.  Of the
latter, 162 had one of their best-preference MX host in a DNSSEC
domain and were in a position to publish DANE TLSA records.  Finally,
10 of those domains actually had TLSA records deployed:

    unitymedia.de
    posteo.de
    bund.de
    jpberlin.de
    lrz.de
    debian.org
    freebsd.org
    ietf.org
    torproject.org
    listserv.state.pa.us

These were already on my curated list, and represent many of its
larger domains.  That list now has 463 DANE email domains.  So
clearly at present most of the deployments are small sites that
are "more agile" in their willingness to deploy early.

If we can clear more deployment roadblocks, I am hoping to see
substantially higher numbers by this time next year.

One deployment pitfall discovered in recent interoperability tests
is that some domains have cleartext-only anti-spam proxies in front
of their MTA, with the proxies only allowing connections to the
real MTA once the SMTP client passes a grey-listing check (this
was observed with "spamd" as the proxy, but any "selective access"
to TLS can be similarly problematic).

If the receiving domain publishes TLSA records, this creates a
catch-22 with DANE-aware client MTAs.  The DANE client never begins
the first mail transaction, because the proxy does not offer
STARTTLS, (the proxy is a receiving system deployed downgrade to
cleartext MiTM in front of the real MTA).

The short-term solution for such domains is to NOT publish TLSA
RRs for port 25.  Longer-term the anti-spam proxy should be upgraded
to support STARTTLS.  For example, the Postfix "postscreen" service,
which has functionality similar to "spamd", supports STARTTLS so that
grey-listing does not amount to a similar downgrade attack.

I'd like to add some language about avoiding this problem in the
operational considerations section of the smtp-with-dane draft.
Any objections?  

Additional operational considerations might include not forgetting
to update TLSA RRs for *all* the names under which a server might
be known when doing key rotation.  This is a problem particularly
when a single wild-card certificate is deployed on all the MX hosts,
and replaced concurrently on them all, creating an immediate outage
for any domains that use variant MX host names (for flexibility of
later hosting some domains separately).  With DANE one should
strongly consider per-server certificates to avoid synchronized
multi-MTA outages.

And lastly, by far the most common problems are with DNSSEC.  A
mixture of failure to perform timely re-signing and at present lots
of domains with nameservers that have non-working Denial of Existence.
I don't have a comprehensive list of software that is deficient in
this manner, but it seems that some older versions of PowerDNS
botch DoE in at least some configurations.  Similar issues reportedly
with djbdns DNSSEC patches.  A few domains have firewalls that
block TLSA queries, one blocked these only for IPv4 clients, with
IPv6 clients not filtered, that can create difficult to diagnose
problems.

So I am looking for guidance on how much *current* operational
experience to include in the draft that may ultimately become
irrelevant as the infrastructure improves, but may be very useful
to get us past the initial deployment hurdles.  If we don't get
early adopters past the initial problems, the long-term obsolescence
of the issues might remain forever in the future.

The DNSSEC issues often impact domains that don't publish TLSA
records, just signing the zone, but operating a nameserver that is
not quite up to spec causes the majority of the problems.  How
should that issue be presented?  It applies to folks who are not
specifically deploying the protocol.  The simplest work-around
is often to publish:

    _25._tcp.<mx-host>. IN TXT "No TLSA RRs here yet"

or to publish real TLSA records, since creating either type of
record avoids most of the DoE bugs.  (I am optimistic that most of
the DoE problems will be remediated by this time next year once
the .nl registrars update their software, and most PowerDNS users
upgrade to a sufficiently recent release).

-- 
	Viktor.