On Tue, Feb 24, 2015 at 08:49:29AM -0800, Paul Hoffman wrote: > On Feb 23, 2015, at 8:33 AM, Sam Hartman <hartmans-ietf@xxxxxxx> wrote: > > Yes, I see significant security problems with this URI. > > It sounds like you have issues with URIs in general, not in a DNS RTYPE > that carries a URI. That is, any URI that has a domain name that can lead > to redirection (though CNAME, DNAME, or SRV) would have the properties > that worry you. It that a fair summary? That's not how I read it. The issue here is that the draft introduces a DNS-based rewrite of the TLS reference identifier. _mumble.example.com. IN URI "https://example.net/"; The draft language stipulates (correctly I think given that DNS also specifies the URI scheme) that DNSSEC is required and the TLS reference identifier becomes "example.net". This is not the case for HTTP with either CNAME or DNAME, and HTTP does not use SRV records. When pre-DANE MTAs use MX records with TLS securely (rather than just going through the motions), they use the nexthop domain (not the MX host domain) as the reference identifier. Similar considerations come into play with RFC 6186 indirection of IMAP and SMTP server locations. RFC 6186 just drops the ball in the user's lap. A more comprehensive solution is hinted at in: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-14#section-7 but I'm not sure where we are whether DNSSEC last-mile is as yet sufficiently addressed for that. Of course with the document under discussion, if mobile applications are in scope, then of course we again need DNSSEC to be usable in last-mile environments. -- Viktor.