Re: [dane] Feedback request: python3-dane (A pure-python DANE library for Python 3)

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 11 December 2014 15:05 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C341ACF0D for <dane@ietfa.amsl.com>; Thu, 11 Dec 2014 07:05:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.4
X-Spam-Level: *
X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_44=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvprZSjEmNFc for <dane@ietfa.amsl.com>; Thu, 11 Dec 2014 07:05:42 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8CB1ACF09 for <dane@ietf.org>; Thu, 11 Dec 2014 07:05:41 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 17D78282F8B; Thu, 11 Dec 2014 15:05:40 +0000 (UTC)
Date: Thu, 11 Dec 2014 15:05:40 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20141211150539.GA25666@mournblade.imrryr.org>
References: <5489774C.5090600@wielicki.name>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5489774C.5090600@wielicki.name>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/4hgTEU6zymT_OFtvPGwdyQrhGB8
Subject: Re: [dane] Feedback request: python3-dane (A pure-python DANE library for Python 3)
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: Thu, 11 Dec 2014 15:05:44 -0000

On Thu, Dec 11, 2014 at 11:51:56AM +0100, Jonas Wielicki wrote:

> I recently started working on a python3 library[1] to support the
> implementation of DANE in python3 based applications. I am looking for
> some support in form of a second or third pair of eyes. As this is a
> security sensitive topic, I would be glad if someone took the time to
> look over the approx. 600 lines of python code or the user interface
> documentation.

Here's my advice.  I fully encourage you to experiment with this
code, as a productive learning exercise.  However, please *do not*
document this as something other than experimental code that you
used to develop your understanding of the various technologies.

Unfortunately, in the DANE space, we have too many "toy" libraries
that are wrong or incomplete, and too few that are correct and
comprehensive, and will be maintained in the long term.

My plan is to see DANE support incorporated into the OpenSSL toolkit,
at which point Python applications will be able to use Python's
OpenSSL support (sufficiently recent, ...) to do DANE validation.

A more valuable contribution would be Python code that locates the
right validated TLSA records for a host:port combination that deals
with CNAME expansion and all the requisite DNS error handling per
the OPs draft.  For extra points, code that does this indirectly
via SRV or MX records, and produces also the correct set of "reference
identifiers" that go along with the TLSA records for handling
certificate usages 0, 1 and 2. This should also handle conversion
of IDNA hostnames to A-label form for DNS lookups and certificate
reference identifier construction.

Then, users of future robust DANE validation libraries will be able
to pass the correct TLSA records and "reference identifiers"
(expected DNS subject names) to those libraries.

Please continue to grow your skills in this space, but learning
and development exercises need to be explicitly labeled as such.
Non-expert users have a hard time distinguishing reliable code from
experiments, and would benefit from fewer choices of higher quality.

As to your questions:

   * Usages PKIX-TA(0) and PKIX-EE(1) never accept chains that
     would fail PKIX validation in the absence of DANE (including
     name checks).  These only "constrain" which chains that pass
     PKIX validation should be accepted.

     Great care must be exercised here, for example, after PKIX
     validation succeeds, a naive request to OpenSSL for the peer's
     chain returns the list of wire certificates, not the validated
     chain.  Additional complications arise due to cross-signing,
     that make it difficult to validate a PKIX chain constructed
     in isolation from the DANE records.  Such a chain might use
     a trust-anchor "below" the one that matches the DANE records.

   * Usage DANE-TA(2) is the most difficult to support, and "toy"
     implementations neglect to perform chain construction and
     integrity checks or perform name checks, apply name constraints,
     depth constraints, handle IDNA conversion of hostnames, ...

   * Usage DANE-EE(3) is generally straight-forward, you just
     check that the peer's certificate or public key has
     the expercted digest.  Even here, integration with the
     TLS library is a good idea, because at some point one
     might want to negotiate the use of "raw public keys"
     when the TLSA records for the peer include records
     of the form "3 1 X", which means that the SSL library
     needs to be aware of the TLSA records *before* the
     handshake.

-- 
	Viktor.