On Wed, May 29, 2013 at 02:21:35PM +0000, Viktor Dukhovni wrote:
> Having understood how the legacy verification process works, what
> errors it detects and reports to the application callback and in
> what order, you are ready to design an extension that implements
> DANE verification.
One more design consideration is a choice of where DNSSEC validation
takes place. The application should be free to use any DNSSEC
validating library of its choice, and then provide validated TLSA
records to the library.
The library may provide a mechanism to find and validate TLSA
records, but this should be optional, and should try to avoid
compatibility constraints on the application (DLL hell) caused by
linking to additional third-party (not bundled with the base
platform) libraries.
The proposed OpenSSL implementation attempts to deal with this by
dynamically loading (rather than linking with) libunbound, but this
brings in its own issues since libunbound links to OpenSSL 1.0.x,
which makes it difficult to test with OpenSSL 1.1.0-dev.
By far the simplest choice is to rely on the system libresolv and
delegate DNSSEC validation to the local (ideally 127.0.0.1)
nameserver. This is what Postfix does, and I believe OpenSSL should
do. Applications that want to validate each time they make a DNS
request via their own trust anchor, can link to a suitable library
of their choice and pass their own TLSA RRs for DANE verification.
Thus OpenSSL should only (directly) support DNSSEC via libresolv,
and should encourage applications that use untrusted remote DNS
caches to link to whatever validating DNS library they see fit.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
