Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

[Pete Resnick <[e-mail]>]

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. - [phone]