[dns-operations] DNSSEC deployment incentives

[Paul Vixie]

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:
> 
> https://tools.ietf.org/id/draft-hallambaker-web-service-discovery-01.html
> 
> 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.
> 
> https://tools.ietf.org/html/draft-hallambaker-mesh-udf-02
> 
> 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.

-- 
P Vixie