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

Jonas Wielicki <jonas@wielicki.name> Thu, 11 December 2014 10:52 UTC

Return-Path: <jonas@wielicki.name>
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 12EC71A878C for <dane@ietfa.amsl.com>; Thu, 11 Dec 2014 02:52:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level:
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
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 GPkjOKDRKc-r for <dane@ietfa.amsl.com>; Thu, 11 Dec 2014 02:52:00 -0800 (PST)
Received: from sol.sotecware.net (sol.sotecware.net [IPv6:2a01:4f8:d16:1305::2]) by ietfa.amsl.com (Postfix) with ESMTP id 904D31AC425 for <dane@ietf.org>; Thu, 11 Dec 2014 02:52:00 -0800 (PST)
Received: from altair.sotecware.net (altair.sotecware.net [217.115.12.84]) by sol.sotecware.net (Postfix) with ESMTPSA id 249771412E2 for <dane@ietf.org>; Thu, 11 Dec 2014 10:51:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wielicki.name; s=k001.sol; t=1418295118; bh=0NjJitSLcz3AJfdiZk/9oDwgi2C+YiOAVyC1GBwQH84=; h=Date:From:To:Subject; b=aBZlmdNUnIR5S1eI9aoNhyAqoECO7GznxkGJEJhVQHa+V8sGtN7a3iRYRfstDFeFZ ChWpPI2uRcSwrrkfSUUlexBkOOLoXVGo8+3eUI9fljDz7gf8Y8crEA8RbH6gdWxnCl /Qxnbp8yAs/o+wbyqlHpZa5G+sEr5oLqvZGx0LgOqsHVrepR/TTGyBxhu5etcyBewF WyDI1MIu9YkOtydeEeVh67fS8eeVZryDP9Gml1yXyGfnzqvKESNlvU5RcK9IKBiLi9 00E9+h5p6p78DsneLz8XOw+nUFixPhS2p78Ag0k1kJ0iT0mmjIo5NJr0/PPMc5w294 acZn2N3y8D6sw==
Message-ID: <5489774C.5090600@wielicki.name>
Date: Thu, 11 Dec 2014 11:51:56 +0100
From: Jonas Wielicki <jonas@wielicki.name>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: dane@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/k1XhPA6PL4Bx8mXUcljoAf3XxWc
Subject: [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
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 10:52:03 -0000

Dear list,

I hope this is not too off-topic, but I guess those most well suited for
the task can be found at this list.

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.

To make it clear what the scope of the library is: It is not a
validating resolver; that is expected to be handled by the application.
it is not a TLS stack or bound to a specific TLS stack. It provides
parsing and hashing of certificates (via the pyasn1 package), as well as
functions to validate a chain of certificates (provided by the
application) used for TLS against a TLSA RRset (provided by the
application) together with the information whether PKIX validation
succeeded (also provided by the application). For PKIX validation, it
provides a facility to extract and validate trust anchors from TLSA RRsets.

I would like a general review (or any kind of feedback for that matter),
but I also have a specific question: I am unsure about the
implementation of the "CA constraint" usage. Is it correct to allow a
"CA constraint" record to enable the use of an otherwise untrusted (but
not invalid, e.g. expired) CA certificate?

Please also take a look at the documentation (for your convenience also
available online at [2]), as it describes the workflow and interface for
developers using the library, which has impact on the achieved security.

If anyone wants to review or take a quick look to see whether I’m doing
the right thing, I would be happy if any issues or feedback to be
reported to me either off-list to this email address, in the github
bugtracker, or on-list if that is considered sufficiently on-topic for
the list. As the library has been published like just now, I assume that
noone has put trust into it yet, so security critical bugs do not need
to be handled privately. If you want to do that nevertheless, use the
GPG key found in the repository (not attaching as it is quite large).
The fingerprint is:

      Key fingerprint = AA5A 78FF 508D 8CF4 F355  F682 E5ED E5AC 679E 300F

thanks for your attention,
Jonas Wielicki

   [1]: https://github.com/horazont/python3-dane/
   [2]: https://docs.zombofant.net/python3-dane/devel/