On Tue, May 28, 2013 at 07:59:19PM +0000, Viktor Dukhovni wrote:
> > Yep, the implementation of usage 2 in the 2.0 release is quite
> > broken. However, the svn version should be better
> > (https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/validator/libval/val_dane.c).
> >
> > Feedback is always welcome.
>
> This version is much better, it does not handle "IN TLSA 2 1 0",
> where only the public key is in DNS, and the chain omits the
> corresponding TA certificate (it starts with a certificate signed
> by the TLSA public key). It is also somewhat inefficient, since
> it repeats the checks in X509_verify_cert() performed during the
> handshake. Doing this via a verify callback rather than via a
> post-handshake function is more natural.
In fact X509_verify_cert() is called for each usage 0/2 TLSA record,
until one matches, each time re-verifying chain properties unrelated
to PKI trust (PKIX or DANE) and calling the application verify
callback multiple times with the same certificates, sometimes reporting
failure, sometimes not.
Another substantial problem is that X509_verify_cert() only checks
the trust store against the top of the peer's certificate chain,
so with usage 0 or 2 if the TLSA record trust anchor is in the
middle of the chain DANE verification incorrectly fails.
To fix this, the chain needs to be copied to a new chain that is
truncated at the top to ensure that the matching TA certificate is
its first element. Full support for "IN TLSA 2 1 0" requires
further non-trivial code (until a future RFC updates 6698 and spells
out a requirement for usage 2 servers to include the TA cert in
their TLS handshake chain in all usage "2 x y" cases except "2 0 0").
My view is that applications should not use this library for DANE
support except on an experimental basis.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
