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