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 Fri, Feb 27, 2015 at 09:41:42AM +0100, Patrik F?ltstr?m wrote:

> So the difference for MX is that the MX model using TLS is wrong.

Specifically, absent DNSSEC+DANE, it is unwise to assume that much
if any security against active attacks results from using the MX
hostname as a peer identity attested via Web PKI CAs.

> Then SRV, can you explain that?
> 
> http://example.com/
> 
> Lookup of SRV for _web._tcp.example.com

Again "nobody" does that for HTTPS (well none of the browsers or
typical web client toolkits do).  Of course someone is probably
doing it some dark corner of the Internet, but they lose all the
usual security properties of TLS (unless they are also doing DNSSEC
+ DANE in this case).  

Plus SRV records don't specify a URI scheme, which can potentially
change the client's security expectations.

SRV records are used for LDAP lookups, often with GSSAPI auth, and
Microsoft (for example) gets it right in creating special principals
for the LDAP servers:

    ldap/<target-fqdn>/<service-domain-fqdn>@REALM

allowing clients to check that the target of the SRV record.
Admittedly GSSAPI often plays out behind enterprise firewalls,
where a lot more insecure DNS redirection is often tolerated than
might be wise on the public Internet.

There is a proposal in RFC 6186 to use SRV records for MUAs
discovering the appropriate IMAP service for their domain.  This
RFC predates DANE, and as I said "drops the ball on the user's lap"
by requiring the user to confirm the redirection.  Even the UTA
DEEP draft does not fully address that issue, thought makes a step
or two in the right direction.

It sure looks like everyone is still rather hesitant around DNSSEC.

> Get back for example 8080 example.net
> 
> http://example.net:8080/
> 
> What I am trying to understand is the _difference_ between URI and MX/SRV which was what Sam said there was.

Applications that use SRV records with TLS, see:

    https://tools.ietf.org/html/draft-ietf-dane-srv

generally use the service domain (not target host) as the reference
identifier, unless they are luck enough to support DNSSEC and DANE
and find a TLSA record for the target host (which was obtained via
a "secure" SRV RRset).

HTTP clients that do TLS, don't do SRV records, or don't understand
the security implications.  All I'm saying is that the security
implications are non-trivial and need discussion.

-- 
	Viktor.