Victor, A simple way to address the concern that Sam raised is to note that DNSSEC's trust model is largely binary, and not subject to alternative trust anchors. That is- parent zone administrator's keys may either be trusted or not. On the other hand, I don't know that this is the draft to take on that issue. It's a fundamental difference between the two models and there are pluses and minuses to each, and it's perhaps worth exploring, but in this draft? Eliot On 3/5/15 7: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. >
Attachment:
signature.asc
Description: OpenPGP digital signature