[dns-operations] DNSSEC deployment incentives

[Phillip Hallam-Baker]

On Wed, Jun 19, 2019 at 2:27 PM Tom Ivar Helbekkmo <tih at hamartun.priv.no>
wrote:

> Paul Vixie <paul at redbarn.org> writes:
>
> > On Wednesday, 19 June 2019 12:57:39 UTC Phillip Hallam-Baker wrote:
> >> On Tue, Jun 18, 2019 at 9:33 PM Viktor Dukhovni <ietf-dane at dukhovni.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.
>
> OK, I'll bite.  My impression has been that DANE is unwanted by the
> large makers of browsers because their owners also earn money from the
> CA business, and widespread use and acceptance of DANE would teach their
> customers that they don't necessarily have to pay for certificates to
> achieve what they want.
>

That is not what they told me.

The big selling point for Google Chrome has been delivering the Web page as
fast as possible. The development team is very concerned with latency. So
any proposal that requires more round trips is a non starter for them. DANE
wasn't the first proposal to use the DNS for PKI. Before that, people were
proposing using DNS to distribute OCSP.

This is why I proposed a DPRIV type protocol several years before that WG
got started. The only way to meet the latency requirement is to upgrade the
DNS client-resolver protocol. One of the big limitations in the
design/implementation of the DNS is that the query protocol effectively
only allows one RR query per request and only one UDP response per request.


To get the browsers on board you would need to be able to offer the TLSA
records with reduced latency. That is not that difficult. While it is
important that DNS client-resolver queries be one packet (Anycast, server
state) there is no problem returning ten packets per request.

But I am not addressing that problem right now because browser providers
are fighting their own battles among themselves and not that interested in
security. If you want to improve the situation there, you need to look at
other deployment areas that are not already committed to one approach.
Which is why I am focused on Web Services. I don't need a single browser
provider to adopt my approach.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190619/8de6e4bb/attachment-0001.html>