On Mon, Mar 6, 2017 at 1:11 PM, Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org>
wrote:
On Mar 6, 2017, at 11:27 AM, Phillip Hallam-Baker
<phill(_at_)hallambaker(_dot_)com>
wrote:
DANE conflates publication of security policy with public key validation
and distribution.
Well, by far the main obstacle to DANE deployment is not this, but
comparatively low
(~0.6%) DNSSEC adoption. Of approximately 1.5 million domains with DNSSEC
for both
the domain and one of the primary MX hosts, 110 thousand (and steadily
growing) have
DANE TLSA records (7% of those who can deploy, given DNSSEC constraints,
have deployed).
The conflation of security policy and key distribution is a late addition
to DANE in
RFC 7672. The base specification in RFC 6698 is rather policy neutral.
So perhaps
tying the two together is in good part my fault. And yet, despite that,
there is
considerably more deployment of RFC 7672 (in SMTP) than of RFC 6698 (in
HTTP, which
was its unstated primary focus).
If you feel strongly that publishing TLSA records should not imply
security policy,
it is not too late to introduce a new policy specification protocol (that
would
still require DNSSEC) to decouple existence of DANE TLSA records from the
desired
security policy. We could then retrofit MTAs to use the policy records
when
present. This would then require two DNS lookups where one suffices, but
might
provide useful flexibility.
Do you have use-cases in which publication of DANE-EE(3) or DANE-TA(2) TLSA
records should not imply a request that sending domains use said records?
My impression is that the adoption obstacle remains operational
difficulties
around DNSSEC and not missing policy hooks.
Again, you are mistaken.
Security Policy can benefit from DNSSEC but it absolutely does not require
DNSSEC to provide value. Since the current Internet security policy is to
require no security, any policy publication mechanism adds value over the
baseline.
The reason DANE cannot progress is precisely that it is tied to DNSSEC in
such a way that instead of DANE getting itself widely deployed and becoming
a reason to deploy DNSSEC infrastructure, it is instead dependent on prior
deployment of DNSSEC so that it cannot succeed until after DNSSEC has been
deployed.
These arguments are not new, they have been rehearsed repeatedly and are
one of the main reasons for not tying policy to key validation. The other
being that the DNS registrars critical to deployment of DNSSEC sell DNS at
a loss and make their profit on the item DANE tries to make free of charge.
Its called a channel conflict and yes, they are show stoppers.