On Wed, Mar 04, 2015 at 04:25:20PM -0600, Pete Resnick wrote: > >I'm going to ask Patrik to publish a revised ID at this point, which I > >expect to see in the next couple of days. > > The new version of the document (-12) is out, announcement attached. It is > now Informational, it removes the discussion of flag "D" for NAPTR, and adds > a bit of discussion to security considerations. I would appreciate folks > giving it a sniff and making sure it addresses your earlier concerns. If so, > I'll go ahead and ballot it for the 12-March IESG telechat. I think this still fails to acknowledge Sam Hartman's concerns about the change in the security model from (often with TLS) application configured trust anchors that may be specific to the expected peer, to likely the ICANN DNSSEC root trust-anchor, or perhaps an enterprise DNS trust-anchor for an internal domain. While such a change in the trust model may well be applicable, there remains in the draft a claim that indirection through DNSSEC is fundamentally not different from indirection through a TLS authenticated HTTP redirect. That claim is likely too bold. Future users of this RR need to consider the issues more carefully. * DNSSEC is often stronger than today's Web PKI DV certs. * However, with the traditional PKI it is far easier to not trust any of the usual suspects and built direct peer to peer trust. * With DNSSEC the most specific one can be is in some cases have a local trust-anchor for the zone apex of the service domain, ( I'm involved in an internal DNSSEC deployment with some secure internal zones with explicit local trust-anchor settings. ) * More broadly however there's just the ICANN root, and perhaps some day the ability to use RFC 5011 to track zsk rollovers of any TLDs that commit to implement the requisite key management discipline. Going beyond that to bilateral trust-anchors between business partner organizations is rather exotic. * All the while various non-browser B2B applications employ explicit destination-specific trust-anchors that perhaps should not be subordinate to the ICANN root or gTLDs. So various problem spaces are better served by the Web PKI, DNSSEC PKI or just bilaterally managed trust anchors, and these are not simply interchangeable. -- Viktor.