On Mon, Mar 6, 2017 at 1:11 PM, Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
> On Mar 6, 2017, at 11:27 AM, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> 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.