[dane] OpenSSL DANE support...

[Viktor Dukhovni <[e-mail]>]

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.