On Tue, Dec 10, 2013 at 11:21:17AM +0000, Ben Laurie wrote:
> > Let's hope that support for DANE verification with OpenSSL will
> > encourage broader application support for DANE. With a bit of
> > luck, someone from the OpenSSL team will volunteer to work with me
> > to integrate the code into the development tree.
>
> I'm willing to consider it.
Thanks. Please drop me a note off list, I'd like to find some
mutually convenient time to chat about the design over a voice
Google hangout. If you want to look at the code first:
https://github.com/vdukhovni/ssl_dane
The work-flow is basically:
SSL_library_init()
SSL_dane_library_init()
SSL_CTX_new()
SSL_CTX_dane_init() /* DANE connections get a dedicated context */
SSL_new()
SSL_dane_init() /* allocate dane state, set SNI, ... */
SSL_dane_add_tlsa() /* Once per record */
SSL_connect() /* off to the races... */
SSL_get_verify_result() /* Learn the outcome */
SSL_dane_cleanup() /* Dispose of DANE state */
You can see this at work in ssl_dane_test.c. It verifies
imap.gmail.com, with all the various usages, selectors, digests
and relevant certificate depths (and out-of-band TLSA records
constructed by pointing the code at a PEM file).
> But I'm still concerned that without something
> akin to CT, DANE is more dangerous than the existing PKI.
[ There is (for various reasons described in the draft) in practice
no *existing PKI* for SMTP, so there is at least one use case where
we're comparing DANE to *nothing* rather than DANE to existing PKI. ]
In any case, the question of the relative merits of DANE in any
particular use-case is rather orthogonal to implementation of the
requisite library support. The decision to use or not use DANE
will happen above the library layer. I should note that my code
does not enable DANE by default for any connections, it does not
even do any DNS lookups. Rather, I provide an API for the application
to explicitly turn on DANE support for a given connection by providing
appropriate parameters (including any TLSA RRs the application
obtained by other means).
> > This took just over 1200 lines of commented code. It should work
> > with OpenSSL 0.9.8 or newer. A very recent insight made it possible
> > to remove the need for signing operations and generation of internal
> > private keys in the verifier, so it is now about as simple as it
> > can get.
> >
>
> 0.9.8 is closed to new functionality, as are some of the more recent
> branches.
I am not changing any existing OpenSSL code, my work is essentially
an add-on library, though tighter integration would be appropriate
in the future and would allow me to simplify the DANE side.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
