Hi Michael et al,
(John, we're sidetracking from your question, as you can probably tell.)
IMHO, the hostname check is immaterial (and potentially confusing, when hosting multiple dc=,dc= trees)
Not sure I understand "immaterial". One would have to right a spec which maps the "name" (here LDAP URL) used by the client to something stored in the TLS server cert.
I meant to say that the name does not have to be checked against the certificate to establish a secure connection. A direct result can be obtained by simply validating through key material:
0. have a dc=,dc= name 1. form a DNS name out of it [RFC 3088] 2. if possible, map to a server hostname with DNS SRV + DNSSEC 3a. lookup the address for the server with AAAA/A (don't care about DNSSEC) 3b. lookup TLSA record for the server with TLSA + DNSSEC 4. connect to the server and start TLS 5. compare the certificate presented with the TLSA data
* step 2 cannot be insecurely denied * step 3a can be caught out as invalid through TLS * step 3b cannot be insecurely faked * step 4 is not conductive to men in the middle or other fakers * step 5 uses information from validated DNS to validate the LDAP server
From the certificate, we need notBefore / notAfter, plus either the
public key or the entire certificate blob in DER encoding. The path above validates the server without needing to look into specific certificate attributes. This is what I like about DANE -- it can be applied to all uses of TLS. Other things I don't like as much.
I expected somebody to raise the DANE hype.
DANE isn't perfect, agreed. In an automated-keying setting, it can add a lot of value, IMHO. (And since we're working towards one, this has my interest.)
Note that DANE requires DNSSEC to be really secure.
Not sure what you mean by "really", but yes, DNSSEC is the basis of trust on which DANE is built. Although it may be used in-addition-to existing certificate infrastructure, whether this is acceptable is the validating party's choice.
Also someone would have to write a spec detailing how to map ldap:///dc=example,dc=com to DANE (DNS) name
You mean in addition to RFC 3088 in the "duplicated locally" variant? This has an implementation in the slapd-dnssrv backend.
RFC 3088 is experimental, but sufficiently accurate I would say; and according to the RFC Editor,
Experimental RFC + Implementation == Independent Submission.
(just like a spec is needed for TLS hostname check).
That's what I think can be entirely avoided with the aforementioned validation path.
What I'm saying is that AFAIK we have all the tools to formally validate foreign LDAP servers, there is no need for anything to be added.
Cheers,
Rick van Rein OpenFortress