Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uni

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.

signature.asc
Description: OpenPGP digital signature