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

[Sam Hartman <[e-mail]>]

>>>>> "Viktor" == Viktor Dukhovni <[e-mail]> writes:

    Viktor> On Mon, Feb 23, 2015 at 03:37:57PM +0000, Viktor Dukhovni wrote:
    >> > I do note that having "priority" and "weight" separated is not
    >> > well-motivated (or even explained) in either this document or
    >> in > the original application.
    >> 
    >> This is simply carried over verbatim from SRV, where priorities
    >> yield strict ordering, while weights (for entries with the same
    >> priority) support weighted load-sharing.  This draft does not
    >> appear to differ from SRV except in replacing target+port with an
    >> URI.

    Viktor> I neglected to comment on the "Security Considerations"
    Viktor> section.

    Viktor> As observed in the DANE SMTP draft
    Viktor> (draft-ietf-dane-smtp-with-dane-14 section 1.3.2) mixing DNS
    Viktor> indirection with TLS significantly changes the security
    Viktor> picture.  The URI draft mentions the need for DNSSEC but
    Viktor> likely understates the significance of the impact.

    Viktor> For example, what determines whether to use TLS?  The target
    Viktor> URI, or some prior policy in the application?  Must URI
    Viktor> RRsets always be DNSSEC validated?  If not what prevents
    Viktor> downgrade attacks to HTTP?  If the DNS (via DNSSEC) is a
    Viktor> critical "trusted entity", should not then TLS use the DANE
    Viktor> PKI (any DNS compromise cannot be compensated for by a
    Viktor> public CA validating a URI that has been redirected to a
    Viktor> hostile site)?

    Viktor> So I take issue with the opening sentence of "Security
    Viktor> Considerations".

    Viktor>     "The authors do not believe this resource record cause
    Viktor> any new security problems."


Yes, I see significant security problems with this URI.

In particular, prior to this URI, your security depends on your TLS
trust anchors.  Since this RR encourages folks to validate the
certificate in the target URI, not the expected name entered by the
user, even if DNSSec validation is done, the security now depends on the
DNS trust anchors and the TLS trust anchors.

For the public web, those trust anchors probably have similar enough
security that it is reasonable to assume they are similar by default.

For most other applications I don't think that's true.  For some
applications i'd expect TLS trust anchors for that application to be
much stronger than DNS trust anchors, while for other apps I'd expect
DNS trust anchors to be much stronger.


I think the security implications of this draft, and by implication the
advisability of this draft have been inadequately considered.  I believe
a last-call is premature at this time.