[dns-operations] DNSSEC deployment incentives

[Mark Andrews]

> On 20 Jun 2019, at 4:59 am, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> On Wed, Jun 19, 2019 at 08:27:34PM +0200, Tom Ivar Helbekkmo via dns-operations wrote:
> 
>> Paul Vixie <paul at redbarn.org> writes:
>> 
>>>> 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.
>> 
>> So why would the presence of Let's Encrypt lead to *less* use of DANE?
> 
> I don't see any evidence that DANE users were doing it to save
> money, even before Let's Encrypt came online.  I would expect DANE
> adoption to be driven by an interest in securing the underlying
> service.  A large fraction of DANE-enabled MTAs (like yours) have
> Let's Encrypt issued certificates, this is even true for one.com
> whose DANE-enabled MTAs serve ~700k customer domains, and use
> Let's Encrypt certs (ACME simplifies cert rollover) with "3 1 1"
> records.
> 
> The frequent certificate rollover with Let's Encrypt does create
> some issues for the sloppier SOHO DANE implementers, because some
> forget to implement a robust process for keeping the TLSA records
> in sync with the frequently updated certificate chain.
> 
> One thing I'd like to see is the ability for a server to use its
> current private key and certs (that match its existing TLSA RRset)
> to use DNS "update" to publish a revised TLSA RRset (perhaps via
> SIG(0) with the TLSA records used as the ACL in the nameserver).
> If any of the implementors of BIND, NSD, PowerDNS, ... are interested,
> please reach out…

What do you want to do the update-policy doesn’t already support?

See grant self and self-sub.  They are designed to allow a machine to
update records associated with itself be the A, AAAA, SRV, TLSA, KEY,
SSHFP with control down to the record type.

Mark

> Better tooling would help, I believe EFF have a work-in-progress
> to make certbot play nice with TLSA records.
> 
>    https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
>    https://github.com/danefail/list/issues/47#issuecomment-456623996
>    https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
> 
>    plus various presentations listed at:
> 
>    https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
> 
> --
> 	Viktor.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org