On 2/24/15 6:02 PM, Viktor Dukhovni wrote: > 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! I think the real issue here we are concerned about is this: Given a slightly modified example from your document: $ORIGIN example.net. _http._web IN URI 10 1 "httpS://www.example.com/" If the intent here is to declare an equivalence between http://example.com and https://www.example.com the problem is that absent DNSSEC one is subject to a downgrade attack. Thus a browser cannot trust the equivalence. Eliot > > 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. >
Attachment:
signature.asc
Description: OpenPGP digital signature