Subject: [ietf-smtp] DANE penetration for MTA/MTA interactions

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Mar 2021 09:50:15 -0700

DANE has been around for a long time.  I'm curious how much actual use 
it gets for email transport.

Is there any sort of subjective or objective assessment of percent of 
sites or traffic using it?

Not just DANE records published, but DANE /use/.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 24 Mar 2021 18:22:39 +0000

On 24/03/2021 16:50, Dave Crocker wrote:
> DANE has been around for a long time.  I'm curious how much actual use it gets for email transport.
> 
> Is there any sort of subjective or objective assessment of percent of sites or traffic using it?
> 

 From my rather small UK ESP, somewhere between 0.1% and 0.01% of outbound
messages are logged as using a DANE-validated connection.
-- 
Cheers,
   Jeremy

---

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 24 Mar 2021 19:40:44 +0000

Dave,

I have previously gathered metrics for our outbound sending using DANE (I've presented at M3AAWG about this), however, we can't know how much inbound mail is using our DANE records.  If you're interested in the outbound numbers, I can send those to you.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -----Original Message-----
> From: ietf-smtp <[email-masked]> On Behalf Of Dave Crocker
> Sent: Wednesday, March 24, 2021 12:50 PM
> To: ietf-smtp <[email-masked]>
> Subject: [ietf-smtp] DANE penetration for MTA/MTA interactions
>
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-
> smtp__;!!CQl3mcHX2A!VkEq09-
> dYqU7XVLyhGfxPtKFrHMVkZmpdtFRWesJs31ORoFkIgEg8GZDTcD7ehTHRB1t
> AtPyhQ$

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 24 Mar 2021 17:12:29 -0400

> it gets for email transport.

I think "long time" is an overstatement, because even with the
specification published in October 2015, it took some years for
implementations in Postfix, Exim, etc. to be shipped, and integrated
into stable OS releases.  It then takes some more years for users to
upgrade to these OS releases, and to choose to enable DANE, which is not
presently enabled by default.

So we're still in the early adoption stages.  It takes a decade or two
for infrastructure technologies to make major transitions.

There is still a non-trivial fraction of MTAs that don't even do
STARTTLS.

    https://transparencyreport.google.com/safer-email/overview

See the table at the bottom of the page, showing mostly cleartext
traffic to Gmail from yahoo.co.jp, uol.com.br, tiscali.it, ...

> Not just DANE records published, but DANE /use/.

At this point, I rather expect that there's still a lot of variability
by user demographics.  In Northern Europe there are likely users for
whom a non-trivial fraction of their correspondents are on systems with
bidirectional DANE.

Some of the folks to ask would be mailbox.org, posteo.de, one.com,
gmx.de, web.de and protonmail.ch, who I believe all have DANE enabled in
both directions, and should have some stats on outbound numbers from a
geographic region where there's more than one provider doing DANE.

In the USA, since the only major provider with DANE is Comcast users
communicating with non-Comcast correspondents (who are not mostly
posting on IETF lists, ...) are likely to not run into much DANE
support at present.

We're still in the early ramp up phase, with DNSSEC enabled for just
2.28% of .COM vs. 56.1% of .NL.  That said, growth is picking up, and
there are some indications that some large players in the USA might
soon start signing at a much greater rate than before.

So taking the long view, I see the current 2.56 million DANE-enabled
domains as good progress to date, making almost 18% of 14.4 million
DNSSEC domains signed.

My personal MTA has logged 131 DANE verified connections out of 511
that used STARTTLS, but this is of course not surprising:

  55 mail.ietf.org
  32 mta.openssl.org
   9 mail.hardakers.net
   7 hummus.csx.cam.ac.uk
   6 mail.nic.cz
   ...

-- 
    Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Mar 2021 14:23:54 -0700

> I have previously gathered metrics for our outbound sending using DANE (I've presented at M3AAWG about this), however, we can't know how much inbound mail is using our DANE records.  If you're inte…

Anything you consider credible.  And I suspect percentage is more useful 
than absolute numbers.  And only rough approximations.  This is more 
like a casual market survey than anything more serious.

Also, any sense of change over time could be interesting.

Thanks!

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Mar 2021 14:30:05 -0700

On 3/24/2021 2:12 PM, Viktor Dukhovni wrote:
> specification published in October 2015, 

DANE was first published in 2012, in RFC 6698.

Even at 2015 -- with RFC 7672, for email -- if operational use is 
miniscule, more than 5 years later, there is a problem.

>     It takes a decade or two

In terms of admin and operations, DANE is quite similar to DKIM.  It did 
not take decades for DKIM adoption to become significant.

> In the USA, since the only major provider with DANE is Comcast users

Using your start date, that's 6 years later with only one major provider?

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 24 Mar 2021 17:50:32 -0400

> DANE was first published in 2012, in RFC 6698.

There were in 2012 no implementations and no specification for how it
interacts with MX records, opportunistic TLS, ...  So the earlier date
is not material.

> miniscule, more than 5 years later, there is a problem.

I disagree.

> > It takes a decade or two for infrastructure technologies to make
> > major transitions.
> 

It isn't even tangentially similar, for many reasons:

    * DKIM is not intended to tackle active MiTM attacks
      and does not require DNSSEC signing of the server's
      zone.

    * DKIM does not require a validating resolver on the
      sending client.

    * DKIM had a strong forcing function in the form of the
      major mailbox providers erecting barriers to non-DKIM
      mail.

    * DANE interects with and overlaps X.509 certificate
      management, which with the advent of ACME (Let's Encrypt,
      ...) complicates the automation of TLSA record updates.
      I hope to release some tooling to reduce friction in the
      next couple of months...

> Using your start date, that's 6 years later with only one major provider?

In the USA, correct.  Largely gated by the fact that the threat model is
on-path active attacks, which therefore requires data integrity in the
DNS signalling.  Hence DNSSEC, which is for the moment still not widely
used in the USA.  Changes are afoot, even Route-53 now offers DNSSEC
and there are strong signals of upcoming shifts at e.g. Godaddy (fingers
crossed).

DANE/DNSSEC is much more akin to IPv6 in terms of adoption, and
comparisons to DKIM are not particularly apt.

-- 
    Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Mar 2021 15:03:49 -0700

>        and does not require DNSSEC signing of the server's

The DNSSec requirement is the major barrier to adoption and it is 
imposed as an operational requirement, rather than a technical one.  It 
is one line in the specification.  Because of slow DANE adoption, there 
was even exploration of doing DANE without the requirement.  My 
impression is that it fizzled.
>      * DKIM does not require a validating resolver on the

The software querying for the key has to do validation.  That's the same 
technical requirement for both mechanisms.

>        major mailbox providers erecting barriers to non-DKIM

There's a lesson there.  I fear it's being missed.

>        I hope to release some tooling to reduce friction in the

Indeed.  DANE is more complicated than DKIM.

> comparisons to DKIM are not particularly apt.

In terms of poor adoption history, that's correct.  My original point, 
however, was in terms of end-to-end basic systems architecture.  In that 
regard, DANE and DKIM are quite similar.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 24 Mar 2021 18:35:47 -0400

On Wed, Mar 24, 2021 at 03:03:49PM -0700, Dave Crocker wrote:

> imposed as an operational requirement, rather than a technical one.

If flows naturally out of the assumption that we're dealing with active
attacks.  Otherwise, if you just want to resist passive monitoring,
STARTTLS is sufficient.  The only other game in town is MTA-STS, which
is a Rube Goldberg contraption with DNS text records, long-term policy
caches, HTTPS services and having to duplicate MX records outside of
DNS.  It isn't gaining broad traction beyond the large providers.

> It is one line in the specification.

It is fundamental to the threat model.

> Because of slow DANE adoption, there was even exploration of doing
> DANE without the requirement.  My impression is that it fizzled.

It never made sense.  Just do STARTTLS if unverified DNS is good
enough, so are unverified certificates.

> The software querying for the key has to do validation.  That's the
> same technical requirement for both mechanisms.

Checking an origin signature on data at rest, via an insecurely obtained
public key (because the attacker is assumed to be a separate fraudulent
origin, not an on-path MiTM) is nothing like what it takes to ensure
downgrade-resistant security against active on-path attacks for the SMTP
transport.

One problem is fundamentally much more difficult that the other.  You
can of course declare ETOOHARD, and move on to other problems, but it
is not appropriate to draw false parallels.

> There's a lesson there.  I fear it's being missed.

If the lesson is that we should settle for MTA-STS, I am not inclined to
agree.  And MTA-STS is hardly a success.  Meantime, Microsoft is
scheduled (delayed from December) to make outbound DANE available in
June (initially it seems opt-in, for interested Azure Exchange
customers, rather than a default setting).  It takes time...

> Indeed.  DANE is more complicated than DKIM.

Yes, because the *problem* it is tackling is fundamentally harder.

> In terms of poor adoption history, that's correct.

s/poor/gradual/.  The current receiver-side penetration for 18% of
signed domains is actually pretty good.  Broad rollout (assuming
progress continues) will take another O(decade).  That's to be expected.

> My original point, however, was in terms of end-to-end basic systems
> architecture.  In that regard, DANE and DKIM are quite similar.

The similarity simply isn't there.  Both use public key algorithms,
that's about it.  Everything that's interesting about them is completely
different.

DANE without DNSSEC would be pointless, because the MiTM is presumed
to control the channel.  DKIM has the luxury of assuming no MiTM,
DANE is tasked with defending against MiTM.  That's not a gulf you
can paper over.

-- 
    Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Mar 2021 16:08:41 -0700

On 3/24/2021 3:35 PM, Viktor Dukhovni wrote:
> attacks.  

As with most problematic security-related designs, there is always an 
entirely reasonable flow of logic.  And yet adoption and use is a 
persistent problem.

The ability to keep ignoring adoption and use barriers, in the name of 
perfection is impressive.

> enough, so are unverified certificates.

Of course it made sense.  It was an attempt to overcome what has proved 
to be a continuing barrier.

Note that were something like that adopted, it would be possible to get 
dramatically wider use of the basic mechanism, and then go and backfill 
with DNSSec later.

And when rejecting such a model, don't compare it to the perfection of 
the fully-integrated model but to the failure of the fully-integrated 
model to get much traction.

> downgrade-resistant security against active on-path attacks for the SMTP

I fear you are changing the point.  The bullet you provided did not go 
into the 'deeper' validation requirements (imposed by DNSSec) but on the 
place of implementation.  I merely noted that both systems have a 
validation requirement for the requestor.

> is not appropriate to draw false parallels.

The difference is the trust hierarchy imposed by DANE's operational 
requirement.

> agree. 

Yes.  It is much better for a mechanism to be adopted at a snail's pace?

> Yes, because the *problem* it is tackling is fundamentally harder.

Note that DANE was developed in response to problems with classic 
X.509-based CAs.

 From the observable adoption curve for DNSSec, it seems to have 
replicated the problematic barrier, albeit through a different mechanism.

> signed domains is actually pretty good.  

1. I noted that number in your earlier note.  Where is this number 
documented?

2. Publication of DNS records is, of course, nice, but it fails on the 
end-to-end test.  The only serious indication of uptake is /use/.

> Broad rollout (assuming

Work on DNSSec began in 1990.  So did IPv6.  You might have the scale of 
the order off, quite a bit.

At any rate, expecting adoption of a mechanism to take a significant 
fraction of people's careers ought to be a red flag.

> that's about it.  Everything that's interesting about them is completely

Take away DNSSec and then please explain the differences, because I'm 
not seeing them.

> to control the channel. 

> DKIM has the luxury of assuming no MiTM,

Actually, that wasn't the basis for DKIM's design.

During discussions, as I recall, there was an explicit view that solving 
MITM for the DNS was quite important, but was a separable problem, 
needing a separate solution.

That is, the requirement was not specific to DKIM.  It was/is not 
specific to any single use of the DNS, but to DNS use generally.  As 
such, it needs it's own solution, where DKIM will ride along for free, 
if/when the ride is meaingfully available.

Note that simply de-coupling DANE from DNSSec allows both to get adopted 
at their own pace.

> DANE is tasked with defending against MiTM.  That's not a gulf you

RFC6698, which defines DANE, does not mention MITM until the Security 
Considerations section.

(Interestingly, before the IESG would authorize creating of the original 
DKIM working group, a requirement was imposed on formulating a basic 
thread analysis that it was responding to.  A similar analysis does not 
seem to be present for DANE...)

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 24 Mar 2021 19:48:45 -0400

On Wed, Mar 24, 2021 at 04:08:41PM -0700, Dave Crocker wrote:

> > It never made sense.  Just do STARTTLS, if unverified DNS is good

Again, unlike DKIM, there's already a transport security mechanism that
ignores MiTM, namely STARTTLS.  It is widely adopted, with adoption
ramping up from ~30% to over 90% (per Gmail's transparency report).

So the SMTP transport security mechanism that uses unsafely obtained
keys for best-effort security already exists, and had a similar ramp-up
time.  It is called STARTTLS, and is a roaring success.

When on-path MiTM is a separate concern, to be tackled later, there is
simply no need for any certificate checks, because TLS key agreement
takes care of ephemeral keying of the channel.

> dramatically wider use of the basic mechanism, and then go and backfill 

It already happened, see STARTTLS.

> model to get much traction.

Nobody rejected STARTTLS, I am a proponent of both unauthenticated and
authenticated opportunistic security.  See RFC7435.

> validation requirement for the requestor.

STARTTLS also checks digital signatures on the handshake.  That's what's
analogous to DKIM.

> The difference is the trust hierarchy imposed by DANE's operational 

The purpose of DANE is to go *beyond* STARTTLS, and harden the transport
against MiTM attacks.  If that's not an issue you care about, you're not
going to rush to adopt DANE, but might do it at some point when
automation makes it a no-brainer to deploy.  We're not yet at the point
where the tools are mature enough to do that.  Progress is being made.

> Yes.  It is much better for a mechanism to be adopted at a snail's pace?

Some things take time.  Meanwhile STARTTLS is doing very nicely.
When can we get the last 10% of the way?

> Note that DANE was developed in response to problems with classic 

Indeed, once the Web PKI boiled down to just DV certs, it became quite
clear that 3rd party CA attestations of "domain control" are weak and
largely redundant.  And there's no effective way to limit trust to
just the domains that a (say national) CA should be able to represent.

> replicated the problematic barrier, albeit through a different

The tools are improving, and the pace of adoption is picking up, I don't
spend much time looking in the rear-view mirror.  Instead of bemoaning
lack of adoption, there are now many people working on removing the
barriers, and making real progress.

> > The current receiver-side penetration for 18% of

    https://mail.sys4.de/pipermail/dane-users/2021-March/000593.html

> end-to-end test.  The only serious indication of uptake is /use/.

Sure, but in the early stages that metric is highly variable across
different demographics.  Some clusters of users have many of their
correspondents with DANE on both sides.  Others, sending email mostly to
large US providers like Gmail, Outlook.com and the like don't end up
using DANE for now.

> the order off, quite a bit.

Well, with DNSSEC being the primary barrier to DANE, now that its
adoption is starting to accelerate, and with now 11 years since the root
zone got signed, some of that ramp up is now well in the past.

For the remaining tasks, my view is: lead, follow or get out of the
way...

> fraction of people's careers ought to be a red flag.

Certainly if one promised something different.  Some things do operate
on that sort of time scale.  Not everything is a bazaar, sometimes we
also need to build a cathedral or two.

> Take away DNSSec and then please explain the differences, because I'm 

STARTTLS already exists.  There's no point in pretending that unsigned
DANE records would add any value.  The purpose of DANE in SMTP *is* to
harden it against MiTM attacks.  It is not a crisis we must solve ASAP.
The STARTTLS stopgap is already in place.

> During discussions, as I recall, there was an explicit view that
> solving MITM for the DNS was quite important, but was a separable
> problem, needing a separate solution.

You were building the STARTTLS analogue, not the DANE analogue.

> Note that simply de-coupling DANE from DNSSec allows both to get
> adopted at their own pace.

I call that STARTTLS, it is done already.  Now we're working on the
longer-term problem that requires DNSSEC integration.

> RFC6698, which defines DANE, does not mention MITM until the Security 

RFC6698 laid the groundwork for DANE, but is just a DNS record format,
it is not a complete protocol.  Actual use of DANE TLSA requires
addressing issues germane to the particular application area.  Hence
RFC7672.  In the case of SMTP, the entire reason is to address active
attacks, I believe I've already mentioned a few times too many that
the solution for the non-MiTM case already existed.

-- 
    Viktor.

---

From: Richard Clayton <[email-masked]>
Date: Thu, 25 Mar 2021 00:03:25 +0000

In message <[email-masked]>, Viktor Dukhovni
<[email-masked]> writes

>The only other game in town is MTA-STS, which

Indeed ... but it fixes the actual real world problem which the large
providers have -- which is that if, even for a short time, large
provider A delivers all the email to large provider B via some foreign
entity's servers then it will be front page news when it is noticed.
Mis-delivering email destined to some less important destination is bad,
but won't make it onto page 47 and that other place can join the gang
any time they decide to care.

Since DNSSEC is currently a non-starter for other parts of A and B's
business -- issues of fragility along with an assessment that it doesn't
solve any of the real problems they face, so the engineering is not
worth investing in -- then it is inherent that that DNSSEC cannot be
used as part of the solution which addresses the problems the mail teams
have to solve.

If standards conformant (cos the large providers really like that) DANE
had not mandated DNSSEC then maybe MTA-STS would not exist.

>enough, so are unverified certificates.

There's a growing literature on why security standards are widely
adopted (and why so many fail) along with a pretty good understanding of
what levers are available ...  at one level TOFU doesn't make sense at
all .. but a great many of our systems depend on it and those who are
moving on to Zero Trust are discovering quite how expensive that can be
and its hard to find examples where there is a return on investment.

- -- 
richard                       writing to inform and not as company policy

"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 24 Mar 2021 20:47:34 -0400

On Thu, Mar 25, 2021 at 12:03:25AM +0000, Richard Clayton wrote:

> >The only other game in town is MTA-STS, which is a Rube Goldberg
> >contraption with DNS text records, long-term policy caches, HTTPS
> >services and having to duplicate MX records outside of DNS.  It isn't
> >gaining broad traction beyond the large providers.
> 
> providers have

That's fine, I don't begrudge them that choice.  I even helped with
crafting the specification.  But since I am not a fan of centralised
email, I think it is healthy to have a cleaner design that isn't
primarily tied to the short-term needs of the largest providers.

In terms of breadth of adoption (number of supporting inbound inbound
domains and MTAs) DANE is presently competing favourably with MTA-STS.

    $ curl -sLo - https://mta-sts.outlook.com/.well-known/mta-sts.txt
    version: STSv1
    mode: testing
    mx: *.olc.protection.outlook.com
    max_age: 604800

    $ curl -sLo - https://mta-sts.yahoo.com/.well-known/mta-sts.txt
    version: STSv1
    mode: testing
    mx: *.am0.yahoodns.net
    mx: *.mail.gm0.yahoodns.net
    mx: *.mail.am0.yahoodns.net
    max_age: 86400

So it looks like the MTA-STS club in the USA is Google and Comcast:

    $ curl -sLo - https://mta-sts.comcast.net/.well-known/mta-sts.txt
    version: STSv1
    mode: enforce
    mx: mx1.comcast.net
    mx: mx2.comcast.net
    max_age: 2592000

    $ curl -sLo - https://mta-sts.gmail.com/.well-known/mta-sts.txt
    version: STSv1
    mode: enforce
    mx: gmail-smtp-in.l.google.com
    mx: *.gmail-smtp-in.l.google.com
    max_age: 86400

with Microsoft and Yahoo still not live with the spec 2.5 years old.

> what levers are available ... 

Some of it is perhaps even reflected in RFC7435.  Again, we have
STARTTLS, that's the cake.  DANE and MTA-STS are icing.

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 24 Mar 2021 21:03:29 -0400

> Indeed ... but it fixes the actual real world problem which the large

Among the top 5000 Alexa domains, MTA-STS is enforced on 16:

    google.com 1
    mail.ru 116
    gmail.com 303
    xfinity.com 675
    openstreetmap.org 710
    wp.pl 1205
    comcast.net 1569
    jetbrains.com 1583
    protonmail.com 2110
    xs4all.nl 2591
    drugs.com 2664
    rte.ie 2775
    arbeitsagentur.de 3784
    govtrack.us 4313
    gsa.gov 4721
    o2.pl 4781

Meanwhile, DANE TLSA records are published for the MX hosts of 30:

    debian.org 271
    ietf.org 336
    xfinity.com 675
    web.de 772
    gmx.net 872
    openssl.org 954
    freebsd.org 962
    bund.de 1304
    navy.mil 1359
    comcast.net 1569
    isc.org 1677
    mpg.de 1816
    cwi.nl 2010
    protonmail.com 2110
    habr.com 2406
    xs4all.nl 2591
    startpage.com 2673
    one.com 2711
    univie.ac.at 2792
    torproject.org 2840
    bayern.de 3276
    uni-muenchen.de 3560
    mail.com 4123
    tum.de 4152
    govtrack.us 4313
    uib.no 4457
    rijksoverheid.nl 4633
    utwente.nl 4651
    cuni.cz 4744
    thalesgroup.com 4820

Just 5 out of the 5000 have both MTA-STS and DANE live:

    xfinity.com 675
    comcast.net 1569
    protonmail.com 2110
    xs4all.nl 2591
    govtrack.us 4313

--
    Viktor.

---

From: "Brotman, Alex" <[email-masked]>
Date: Thu, 25 Mar 2021 13:39:18 +0000

Over the course of 24hrs, we have:

* About 55% using STARTTLS or None
* 35% using MTA-STS (regardless of policy)
* 10% using DANE

A few notes about this.  DANE is higher for us due to an MX which covers several internal domains also being protected with DANE.  Without that MX in the results, DANE is about 0.5%.  Note that we send mostly US-based P2P mail, largely going to the three larger providers (all of which are using some level of MTA-STS, though I find it curious that yahoo.com has MTA-STS, but aol.com does not).  Our largest DANE destinations are Protonmail, 1and1/1und1, and US Gov't entities.  Over the past two years, the raw volume for DANE deliveries has nearly tripled.  FWIW, MTA-STS mode is about 75% enforce/25% testing.  Of the TLSRPT reports (not a huge number) we have received over the past 15d, they've all referenced our MTA-STS as the controlling policy type.

Be good to get numbers from someone in Europe (NL or DE perhaps) and see how they compare.  I'd expect they have a bit more DANE than we do.

> Sent: Wednesday, March 24, 2021 5:24 PM
> To: Brotman, Alex <[email-masked]>; [email-masked]; ietf-
> smtp <[email-masked]>
> Subject: Re: [ietf-smtp] DANE penetration for MTA/MTA interactions
>
> > I have previously gathered metrics for our outbound sending using DANE
> (I've presented at M3AAWG about this), however, we can't know how much
> inbound mail is using our DANE records.  If you're interested in the outbound
> numbers, I can send those to you.
>
> than absolute numbers.  And only rough approximations.  This is more like a
> casual market survey than anything more serious.
>
> smtp__;!!CQl3mcHX2A!UHMM9nkIJk1BWxnRRLszeKu-UYznWVBVT6EEK-
> isBnlaTyyhDoFAvHokxuqovU5tO__Oe6ZIdQ$