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.