> On 27 Feb 2015, at 10:24, Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote: > > 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). I understand that part, but for me (maybe wrongly) I think "badly designed RR Type" is a different argument than "SRV is different from URI". If both are crap, then I understand :-) > Plus SRV records don't specify a URI scheme, which can potentially > change the client's security expectations. Ok, got it! Thanks! > 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 Ok. > 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. Yeah, for some for me weird reason... "Just do it!" I am btw also of the view that DNSSEC is so darn important that I think having validation in (the trusted) recursive resolver one uses is better than using the current CA/X.509 PKI. Sure, local validation in application is much much better, but I rather have/use DNSSEC with validation in recursive resolver than no DNSSEC. I.e. if I do not trust the zeroconf we have today, then I am sort of toast anyways. >> 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. Thanks! That they are non-trivial, absolutely! I was the statement by Sam that SRV and MX did *not* have these security implications URI have I wanted to know more about. Patrik
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail