[dane] OpenSSL DANE support...

Viktor Dukhovni <viktor1dane@dukhovni.org> Tue, 10 December 2013 18:27 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2BBD51AE171 for <dane@ietfa.amsl.com>; Tue, 10 Dec 2013 10:27:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YvSmZhEfWQ7E for <dane@ietfa.amsl.com>; Tue, 10 Dec 2013 10:27:16 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org []) by ietfa.amsl.com (Postfix) with ESMTP id 36AC31AE052 for <dane@ietf.org>; Tue, 10 Dec 2013 10:27:15 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E15582AB16E; Tue, 10 Dec 2013 18:27:09 +0000 (UTC)
Date: Tue, 10 Dec 2013 18:27:09 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20131210182709.GE761@mournblade.imrryr.org>
References: <A06891E1-01E0-40CC-A9A2-171CAA39AB79@kumari.net> <20131205175314.GH761@mournblade.imrryr.org> <E78C07CA-B742-43B2-8848-33DEB22A8014@kumari.net> <201312080234.rB82YeoW029387@new.toad.com> <m3y53tg0c3.fsf@carbon.jhcloos.org> <20131209231919.GY761@mournblade.imrryr.org> <4FAF6906-D258-4AB3-B76C-888C35566097@kirei.se> <20131210073402.GA761@mournblade.imrryr.org> <CABrd9SSSPFOe7HGyFiH=8oP=cvQ-g6HEqBytY8h=bbVonwNR7w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABrd9SSSPFOe7HGyFiH=8oP=cvQ-g6HEqBytY8h=bbVonwNR7w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [dane] OpenSSL DANE support...
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 18:27:18 -0000

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:


The work-flow is basically:

	SSL_CTX_dane_init()	/* DANE connections get a dedicated context */
	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.