[dns-operations] DNSSEC deployment incentives

[Phillip Hallam-Baker]

On Tue, Jun 18, 2019 at 7:07 PM Paul Vixie <paul at redbarn.org> wrote:

> On Tuesday, 18 June 2019 21:31:51 UTC John R Levine wrote:
> ...
> >
> > There's no question that CAs are very broken, but there's also no
> question
> > that browsers have been reluctant to use TLSA so you can't actually
> > depend on it.
>
> there was a time when we couldn't depend on EDNS. and on DNS. and on SMTP.
> and
> on IPv6. all of those had pre-existing competitors. we made these new
> things
> relevant by ignoring the wishes those who preferred the old ways. as we
> will
> with DANE.
>

The browsers stated what they wanted from DANE, the WG ignored them
completely and told them to take a hike. That was almost a decade ago now.
I don't see any reason to think things are going to change.

There is no reason to think that DANE is going to deploy automatically
simply by waiting longer. The DNS registrars have no interest in supporting
the TLSA record using the tools they make available to the vast majority of
their customers. They won't do that because it will take cash out of their
pocket.

The way to make use of the DNSSEC to distribute security policy is through
records that the registrars do support. i.e. TXT and SRV. Putting prefixed
TXT records in the DNS is a deployable option because you are not asking
any party to act against interest.

TLSA has not worn well. It is tied to a single aspect of a single security
enhancement. The features I want from security policy are to know

* Fingerprint of the root of trust for the service authentication cert.
* Key exchange key for the host that can be used to encrypt the service key
exchange
* Specification of security protocol(s) supported

TLSA only addresses the first of those.
And BTW: If we count trust roots the way that the EFF did, DNSSEC has a
million trust roots (or however many zones are signed) not one. It was an
utterly bogus comparison.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190618/9139ebc5/attachment.html>