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.