On 13 Apr 2021, at 0:27, Nico Williams wrote:
On Mon, Apr 12, 2021 at 03:17:32PM -0700, Michael Thomas wrote:
(1) may have been because of (2), and I believe (2) was because of
internal technical and political issues. I.e., I would not consider
it
dispositive that Google seemed to like DANE then gave up on it,
though
that and why they did certainly is germane.
Yes, that's what I would assume as well. Build it and they will come
has a
sterling track record of failure in IETF.
Building a technical spec is not enough, indeed. DANE hasn't
succeeded
yet, and neither has DNSSEC. But DANE is starting to gather steam (in
no small part due to Viktor's efforts) in the realm of SMTP. The fact
that DANE was early for its time doesn't mean that the single root and
unyielding name constraints aren't appealing or appealing enough to
make
a more serious try now.
As noted, the tooling for DNSSEC has been substantially improved in
recent years. Implementations of DANE do exist now. There are a
number
of missing elements, such as a TLS extension to staple DANE that
supports authenticated denial of existence. We're making progress
though. It may seem slow, but there may be a preference cascade at
some
point. It may only take enough user-agent, and registrar / domain
hosting services to provide this functionality to make it popular.
There’s been too much focus on getting browsers to implement
HTTPS/DANE. These days HTTPS is used for all kinds of stuff that has
nothing to do with the web. Take the Fediverse for example. ActivityPub
uses HTTPS for server-server communication in a manner similar to how
MTAs use SMTP. There are plenty of other examples.
My point is that if people want to see HTTPS/DANE deployments grow they
should start hacking HTTPS/DANE validation into the numerous open source
projects that act as HTTPS clients. Find communities of geeks to act as
early adopters, and simply ignore the politics of large browser vendors
as they’re obviously a lost cause.
—Andrew
