[dns-operations] DNSSEC deployment incentives
paul at redbarn.org
Wed Jun 19 17:18:43 UTC 2019
Phillip Hallam-Baker wrote on 2019-06-19 09:54:
> On Wed, Jun 19, 2019 at 11:43 AM Paul Vixie <paul at redbarn.org
> > > But Let's Encrypt de-monetized certificate issuance, so now that
> > > obstacle is moot.
> > It has also eliminated the incentive to deploy DANE for free certs.
> not for me, but i think you may be right in general.
> That depends on whether your objective here is to deploy DANE TLSA
> records or solve the problems they were originally intended to address.
there wasn't a single "original intention". i had qualms about TLSA but
i chose to live with it because it was close enough -- like most
standards, there was a problem statement mismatch (against my own hopes
and dreams). apparently there were hardliner elsewhere in the ecosystem
who took a "my way or the highway" approach, and declined to deploy. i
suggest holding one's nose to avoid the bad smell, as we must all do
with dnssec itself.
i don't want to depend on a "lets encrypt" model, due to coupled
external dependencies. i don't want to trust everybody whom my OS vendor
or my browser vendor has chosen to trust, to introduce me to anybody
else's keys. while i don't love the single-root trust system of DNSSEC,
i do love only having to do vetting on one root rather than on many, and
i appreciate the transparency of ICANN's key management operations and
of the trust-follows-delegation model. i'll be happy when DANE takes off
for more protocols, because revocation is a matter of secure deletion of
keying material, and doesn't require lookaside to revocation authorities.
this was never going to be elegant, and no one person was going to love
100% of it. that was in the cards, not how we played them.
> We have tried four separate end-to-end mail enhancement protocols over
> the years, PEM, MOSS, OpenPGP, S/MIME. Why should we assume that if the
> DANE WG couldn't deliver that nobody can?
the DANE WG delivered something i can live with, that solves my own CA
problem. no doubt there are others in the CA world or the TLS world who
have larger or smaller problems than what DANE TLSA solves. i was not
expecting any support from the CA industry which TLSA may disrupt, and
perhaps there's enough overlap between the CA and WWW industries that
they are making common cause here for reasons of simple solidarity. i'll
never know. i do know that TLSA is working fine for e-mail, and i know
of no defects so all-encompassing that they would prevent TLSA from
working for HTTPS also. in short, i think you're encoding your
perspective into your conclusion here.
> The big problem with DANE is that they got the architecture wrong from
> the start. The way to get security policy to work is to consider it as a
> part of a comprehensive service discovery mechanism based on the SRV
> mechanism which you invented and Stuart Cheshire et. al. extended with
> the companion TXT records.
that way would also work, though i note with dismay that the WWW
industry has resisted all calls for SRV support, since day 1, and as a
result, there's now great effort expended to standardize "ANAME", which
would have been moot if the WWW community hadn't resisted "SRV". do we
both see history repeating, and are we both sanguine about it?
> My proposal for doing this is here:
> You will note that almost the entire spec is constrained by the previous
> SRV and DNS Service discovery drafts. The only thing I introduce that is
> new is a BASE32 mechanism for presenting fingerprints of security
> policies, root certificates etc. etc.
> This approach provides a superset of DANE capabilities without the need
> for any new records. It allows the security policy description to be
> obtained with a minimal number of round trips and the mechanism can be
> used for discovery of any service. Thus an authoritative DNS server can
> provide all the information required for service connection in a single
> round trip as additional RRs.
> DANE was a wasted opportunity because they started from the wrong place.
i think it's misleading and unwise to speak of DANE in the past tense.
at a glance, your proposals were better. but many proposed alternatives
to DNSSEC were (and remain) better than DNSSEC, too. technical merit is
not the decisive criteria here. in the ietf's rough consensus model, we
stop arguing when everybody is equally unhappy and exhausted; not before.
More information about the dns-operations