<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Tue, Jun 18, 2019 at 9:39 AM Mal via dns-operations <<a href="mailto:dns-operations@dns-oarc.net">dns-operations@dns-oarc.net</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>From: Mal <<a href="mailto:malz@jetlan.com" target="_blank">malz@jetlan.com</a>><br>To: Bill Woodcock <<a href="mailto:woody@pch.net" target="_blank">woody@pch.net</a>>, Jim Reid <<a href="mailto:jim@rfc1035.com" target="_blank">jim@rfc1035.com</a>><br>Cc: DNS Operations List <<a href="mailto:dns-operations@dns-oarc.net" target="_blank">dns-operations@dns-oarc.net</a>><br>Bcc: <br>Date: Tue, 18 Jun 2019 21:23:46 +0930<br>Subject: Re: [dns-operations] DNSSEC deployment incentives<br><br>
<br>
On 18/06/2019 7:46 pm, Bill Woodcock wrote:<br>
> When I authenticate to my server, I’d prefer it to actually be my server. <br>
>     <br>
>                 -Bill<br>
> <br>
<br>
Why not get some TLSA records going for that server too Bill, if you're<br>
using TLS?  Postfix plays real nice with DNSSEC & DANE.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div><br></div><div><div class="gmail_default" style="font-size:small">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.</div><br></div><div><a href="https://tools.ietf.org/html/draft-hallambaker-iab-deployment-00">https://tools.ietf.org/html/draft-hallambaker-iab-deployment-00</a><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">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?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><br></div><div><div class="gmail_default" style="font-size:small">The way to deploy DNSSEC is to create an incentive to deploy and validate records that provide value to the party publishing them.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Another approach is to put security related information into the DNS and allowing but not requiring DNSSEC. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><br></div></div></div>