On Wed, Mar 24, 2021 at 03:03:49PM -0700, Dave Crocker wrote:
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.
The DNSSec requirement is the major barrier to adoption and it is
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.
* DKIM does not require a validating resolver on the
sending client.
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.
* DKIM had a strong forcing function in the form of the
major mailbox providers erecting barriers to non-DKIM
mail.
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...
* 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...
Indeed. DANE is more complicated than DKIM.
Yes, because the *problem* it is tackling is fundamentally harder.
DANE/DNSSEC is much more akin to IPv6 in terms of adoption, and
comparisons to DKIM are not particularly apt.
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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp