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
enough, so are unverified certificates.
Of course it made sense. It was an attempt to overcome what has proved
to be a continuing barrier.
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.
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.
It already happened, see STARTTLS.
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.
Nobody rejected STARTTLS, I am a proponent of both unauthenticated and
authenticated opportunistic security. See RFC7435.
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.
STARTTLS also checks digital signatures on the handshake. That's what's
analogous to DKIM.
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.
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.
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?
Some things take time. Meanwhile STARTTLS is doing very nicely.
When can we get the last 10% of the way?
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.
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.
From the observable adoption curve for DNSSec, it seems to have
replicated the problematic barrier, albeit through a different
mechanism.
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
signed domains is actually pretty good.
1. I noted that number in your earlier note. Where is this number
documented?
https://mail.sys4.de/pipermail/dane-users/2021-March/000593.html
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/.
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.
Work on DNSSec began in 1990. So did IPv6. You might have the scale of
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...
At any rate, expecting adoption of a mechanism to take a significant
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.
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.
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.
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.
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.
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.
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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp