On 27 Feb 2015, at 10:24, Viktor Dukhovni <ietf-dane(_at_)dukhovni(_dot_)org>
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
signature.asc
Description: Message signed with OpenPGP using GPGMail