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

[Viktor Dukhovni <[e-mail]>]

On Mon, Feb 23, 2015 at 11:33:11AM -0500, Sam Hartman wrote:

>     Viktor>     "The authors do not believe this resource record cause
>     Viktor> any new security problems."
> 
> Yes, I see significant security problems with this URI.

With MX and SRV indirection, prior to DNSSEC/DANE, TLS applications
have generally used the service domain (not the target domain) as
the relevant reference identifier.  Also MX and SRV records do not
specify whether TLS is or is not to be used, that decision is made
by other means.  Here, the language specifies using the target,
which makes the DNS trusted as with DNSSEC/DANE and this seems
unavoidable, because the URI includes the scheme!

One might make the case that it is not the new DNS RRtype itself
that changes the security model.  Rather, it would be its use in
with a particular protocol.  This document then just provides the
means, and future documents specify when URI records are (or are
not) to be applied to a particular application protocol.  The draft
then just defines the record type format, with specific discussion
of when to use it, exactly how to decide whether TLS is required
and which PKI to use deferred to documents that specify a particular
application context.

> 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.

Yes, both, in a way that means that compromise of either breaks
security.  So at the very least, I would advocate to go with DANE
for verification: in for a penny, in for a pound!  Adding a second
set of trusted parties increases exposure without any compensating
increase in security.

-- 
	Viktor.