[dns-operations] DNSSEC deployment incentives

[Phillip Hallam-Baker]

On Wed, Jun 19, 2019 at 11:43 AM Paul Vixie <paul at redbarn.org> wrote:

> 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.
>

That depends on whether your objective here is to deploy DANE TLSA records
or solve the problems they were originally intended to address.

We have tried four separate end-to-end mail enhancement protocols over the
years, PEM, MOSS, OpenPGP, S/MIME. Why should we assume that if the DANE WG
couldn't deliver that nobody can?

The big problem with DANE is that they got the architecture wrong from the
start. The way to get security policy to work is to consider it as a part
of a comprehensive service discovery mechanism based on the SRV mechanism
which you invented and Stuart Cheshire et. al. extended with the companion
TXT records.

My proposal for doing this is here:

https://tools.ietf.org/id/draft-hallambaker-web-service-discovery-01.html

You will note that almost the entire spec is constrained by the previous
SRV and DNS Service discovery drafts. The only thing I introduce that is
new is a BASE32 mechanism for presenting fingerprints of security policies,
root certificates etc. etc.

https://tools.ietf.org/html/draft-hallambaker-mesh-udf-02

This approach provides a superset of DANE capabilities without the need for
any new records. It allows the security policy description to be obtained
with a minimal number of round trips and the mechanism can be used for
discovery of any service. Thus an authoritative DNS server can provide all
the information required for service connection in a single round trip as
additional RRs.

DANE was a wasted opportunity because they started from the wrong place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190619/72015fce/attachment-0001.html>