ietf
[Top] [All Lists]

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

2015-03-05 10:08:49
"Viktor" == Viktor Dukhovni <ietf-dane(_at_)dukhovni(_dot_)org> 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.

<Prev in Thread] Current Thread [Next in Thread>