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

Jonas Wielicki <jonas@wielicki.name> Fri, 12 December 2014 10:24 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 AFC581ACC88 for <dane@ietfa.amsl.com>; Fri, 12 Dec 2014 02:24:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] 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 XmcbwiC7hg3l for <dane@ietfa.amsl.com>; Fri, 12 Dec 2014 02:24:10 -0800 (PST)
Received: from sol.sotecware.net (sol.sotecware.net [IPv6:2a01:4f8:d16:1305::2]) by ietfa.amsl.com (Postfix) with ESMTP id 850C51ACC7F for <dane@ietf.org>; Fri, 12 Dec 2014 02:24:09 -0800 (PST)
Received: from [IPv6:2a00:1328:e101:b04::1] (whiterabbit.sotecware.net [IPv6:2a00:1328:e101:b04::1]) by sol.sotecware.net (Postfix) with ESMTPSA id 455481412E2 for <dane@ietf.org>; Fri, 12 Dec 2014 10:24:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wielicki.name; s=k001.sol; t=1418379847; bh=H4OzgQv1+KY0i2w2ZUHdNDPuydG/x1b9yDCJDSjgbms=; h=Date:From:To:Subject:References:In-Reply-To; b=qAtOSaTTIoTuU4ZqqFWPEDyg9X3lrm52/xhKw8uYjtb6Qbyk5Z++4iW+6TFh2QNSX 1tlqR8GpFRn5MH69WOs7Nb0MhjPQMT0cgeuz9CMhmi3iOYuVUbIfQeXKn+clc32IQg wBRcAQ/0ntYFt+lAYL7dwBKfMVJniQ03o6Zzk31VmibUJ3e+y5pKR+oFxuJqkqo62N 3qY0l0vGiM+ualXn6iXCs2L95WuylZK7/uHJuXgzHpYHezG7ihCB+3MdjxE26res+u 2Z1cFppIIlT84PthKvrru6/NQ05rhv2DNyYVNL+5P6XAlVzKLc5eHG9D1+i43p/xwP cDUKH3dP68EEw==
Message-ID: <548AC246.8090004@wielicki.name>
Date: Fri, 12 Dec 2014 11:24:06 +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
References: <5489774C.5090600@wielicki.name> <20141211150539.GA25666@mournblade.imrryr.org>
In-Reply-To: <20141211150539.GA25666@mournblade.imrryr.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/aYsflN4MGRfYPnSpggD9AEDR8wY
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
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: Fri, 12 Dec 2014 10:24:12 -0000

Dear Viktor,

On 11.12.2014 16:05, Viktor Dukhovni wrote:
> 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.

I understand your concerns and I have added a note to the README and a
huge red warning to the autogenerated docs.

> 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.

I agree that this indeed is also a field of problem. However, I
currently don’t dare to implement a DNSSEC validating resolver, which
would be required for this task (or, again, offload the burden of
ensuring such a resolver is present to the user, which is generally
error-prone). There is DNSPython, which has some DNSSEC utilities, but
as far as I know does not provide validation support.

Thank you for giving me the hint to the draft though. I did not know
that it existed and it provides valuable insights on the workings of DANE.

> * 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.

Thank you, that answers my question.

> 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.

But I assume that one can obtain the actually validated chain using
the verify_callback mechanism provided by OpenSSL?

> 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.

I read about that in the draft. I think this is unfortunate, as it
really requires to meld the support into the PKIX validating library,
something I hoped could be avoided (or, alternatively, validate
yourself, as you appearantly did in the postfix DANE code).

> * 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, ...

I wonder whether adding certificates provided by DANE-TA records
(assuming we have a Cert+Full record) to the trusted store of the SSL
implementation (only for that particular connection) and check whether
these have been used after the fact would be sufficient?.

thank you for your input,
Jonas Wielicki