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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "Viktor" == Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> writes:

    Viktor> 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.

    Viktor> I think this still fails to acknowledge Sam Hartman's
    Viktor> concerns about the change in the security model from (often
    Viktor> with TLS) application configured trust anchors that may be
    Viktor> specific to the expected peer, to likely the ICANN DNSSEC
    Viktor> root trust-anchor, or perhaps an enterprise DNS trust-anchor
    Viktor> for an internal domain.

    Viktor> While such a change in the trust model may well be
    Viktor> applicable, there remains in the draft a claim that
    Viktor> indirection through DNSSEC is fundamentally not different
    Viktor> from indirection through a TLS authenticated HTTP redirect.
    Viktor> That claim is likely too bold.  Future users of this RR need
    Viktor> to consider the issues more carefully.

The claim in the draft is:
>   comparison, and that the change in what hostname to use is secured by
>   DNSSEC so that it can be trusted in a similar way as a redirect in
>   HTTP using TLS.

I'm actually OK with that claim in an informational RFC because of the
word similarly.
I think the current version is good enough for informational.
I think Eliot's proposal 


>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.  

would improve the text, but I'm OK with the draft as-is.
Thanks for diligent work resolving raised concerns.





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]