>>>>> "Viktor" == Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> 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.