On Tue Sep 14 01:03:39 2010, Stefan Santesson wrote:
Under the current rules, using this example I read it that the
following
apply:
- If you are just checking the SRVName you will not learn the
legitimate
host DNS name. So a certificate issued to host2.example.com will be
accepted
even if you intended to contact host1.example.com (even if that
information
is in the cert).
But I don't care about the legitimate hostname. All I care about is
that my TLS endpoints are me, and the service I wanted. What hostname
that service happens to be delivered on is entirely immaterial. If I
*did* care about that, I'd surely also want to verify the IP address,
and then I'd want to verify the MAC address, and then the CPUID, and
then...
Surely if an sRVName (or equivalent) fully matches, this is
sufficient to verify that the contacted host is authorized to provide
that service for that domain?
- If you just check the dNSName, you will miss the fact that you
talk to the
desiganted ldap server and not the xmpp server (even if that
information is
in the cert).
Kind of. The rules effectively mean that dNSName is treated as a
sRVName with a wildcard service type, as I understand it.
If I'm not totally wrong in my example above I also think it would
be good
with a security note stating that an SRVName may not provide the
full host
DNS name, and if it is important to verify the host DNS name, you
must
verify the dNSName in addition to what else you are checking.
I don't see any time when it's desirable, from a security
perspective, to check the host name in addition to the service domain
name.
Dave.
--
Dave Cridland - mailto:dave(_at_)cridland(_dot_)net -
xmpp:dwd(_at_)dave(_dot_)cridland(_dot_)net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf