ietf-smtp
[Top] [All Lists]

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

2021-03-24 18:09:39
On 3/24/2021 3:35 PM, Viktor Dukhovni wrote:
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.

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.



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.

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.


      * 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.

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.



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.

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



      * 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.

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



Indeed.  DANE is more complicated than DKIM.

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.


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.

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
progress continues) will take another O(decade).  That's to be expected.

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.


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.

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


DANE without DNSSEC would be pointless, because the MiTM is presumed
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
can paper over.

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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp