A specific text suggestion (even better if you and Sam were to agree on
it) would be greatly appreciated.
pr
On 3/5/15 12:45 AM, Viktor Dukhovni wrote:
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.
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478