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.