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(_at_)mit(_dot_)edu>
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.