[dns-operations] DNSSEC deployment incentives

[Phillip Hallam-Baker]

On Tue, Jun 18, 2019 at 9:39 AM Mal via dns-operations <
dns-operations at dns-oarc.net> wrote:

>
> From: Mal <malz at jetlan.com>
> To: Bill Woodcock <woody at pch.net>, Jim Reid <jim at rfc1035.com>
> Cc: DNS Operations List <dns-operations at dns-oarc.net>
> Bcc:
> Date: Tue, 18 Jun 2019 21:23:46 +0930
> Subject: Re: [dns-operations] DNSSEC deployment incentives
>
>
> On 18/06/2019 7:46 pm, Bill Woodcock wrote:
> > When I authenticate to my server, I’d prefer it to actually be my
> server.
> >
> >                 -Bill
> >
>
> Why not get some TLSA records going for that server too Bill, if you're
> using TLS?  Postfix plays real nice with DNSSEC & DANE.
>

I did try to start this discussion 19 years ago after VeriSign bought
Network Solutions so we could deploy DNSSEC. There is only one good reason
to deploy DNSSEC and that is to publish security policy.

There are many issues surrounding DNSSEC deployment. One of them was that
the DANE people managed to cripple it by setting up a disincentive for the
DNS Registrars to support it. The registrars mostly sell DNS names at cost
and make money on an upsell to SSL certs. So making the incentive for
DNSSEC deployment taking the crust from the mouth of those needed to deploy
it was a bit clueless to say the least.

https://tools.ietf.org/html/draft-hallambaker-iab-deployment-00

At this point, DANE is an obstacle to DNSSEC rather than an incentive and I
rather suspect that this is what the NSA BULLRUN folk planned all along.
Why else spend so much time driving away Ben Laurie and the Google Chrome
team?

Another problem with DNSSEC is that it has a single root of trust, that is
ICANN. Russia is not going to allow a US corporation to establish itself as
the ultimate signing authority. Nor should they. If DNSSEC were deployed
according to the IETF specs, the concentration of power would be
intolerable. All it would take is one idiot US Congressman to decide he can
make Senator by passing a bill to force ICANN to drop Cuba out of the root
and off the Internet. Of course that isn't going to happen but nor are
other countries going to allow a situation where it is even a possibility.

The way to deploy DNSSEC is to create an incentive to deploy and validate
records that provide value to the party publishing them.

One such incentive is the ability to move the DNS records over alternative
transports (e.g. HTTP). The authentication provided by the DNS protocol is
horribly weak but it is not zero. Moving signed DNS records over HTTP in
the header of content linking to those sites is stronger authentication and
saves a round trip or so.

Another approach is to put security related information into the DNS and
allowing but not requiring DNSSEC.

I have a mechanism that allows a Mesh client to encrypt the start of a key
exchange using an x25519 key presented in a TXT record. The same could be
added to TLS. This exchange does not require DNSSEC but people using it
will almost certainly want to upgrade and especially so if there is UL type
accreditation program.


The problem with anything related to security policy or service
configuration is that it has zero value unless the data provided is
accurate. Which means that it cannot have been produced by manual DNS
config. A protocol for automating DNS service config is therefore a
necessary precondition for any of these schemes described.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190618/04d3b917/attachment.html>