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-02-23 09:53:34
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.

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

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

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

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

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

I think the use of DNS indirection via URI RRs (as also with SRV,
MX, ...) profoundly changes the security model for TLS.

-- 
        Viktor.

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