[dane] DANE-TA(3) and DANE-TA(2) certificate content semantics

Viktor Dukhovni <viktor1dane@dukhovni.org> Sat, 01 March 2014 19:07 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 3E7E81A0A3E for <dane@ietfa.amsl.com>; Sat, 1 Mar 2014 11:07:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CJtqftrB1Tmv for <dane@ietfa.amsl.com>; Sat, 1 Mar 2014 11:07:56 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org []) by ietfa.amsl.com (Postfix) with ESMTP id 8A3DB1A0A3D for <dane@ietf.org>; Sat, 1 Mar 2014 11:07:56 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 602CB2AB24B; Sat, 1 Mar 2014 19:07:52 +0000 (UTC)
Date: Sat, 1 Mar 2014 19:07:52 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140301190752.GL21390@mournblade.imrryr.org>
References: <20140215164446.GN278@mournblade.imrryr.org> <20140217133057.2BDF41AC10@ld9781.wdf.sap.corp> <20140217181533.GG278@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140217181533.GG278@mournblade.imrryr.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ziPlCpz2ZqrNFOyDw5pmy_RSgAA
Subject: [dane] DANE-TA(3) and DANE-TA(2) certificate content semantics
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: Sat, 01 Mar 2014 19:07:59 -0000

On Mon, Feb 17, 2014 at 06:15:33PM +0000, Viktor Dukhovni wrote:

So one of the important issues to be discussed in London (and of
course on the list) is the question of DANE TLSA records pre-empting
some or all of the content of the associated certificate:

> So I can live with a weaker requirement, if that settles the issue.
> With DANE-EE(3):
>     - No PKIX signature verification.  Covered by TLSA association
>       data field, and in any case we don't have a trusted issuer
>       whose signature can be checked.  [ Obvious. ]
>     - No name checks based on certificate content.  Covered
>       by TLSA (service, protocol, base domain) triple.  [ Already agreed. ]
>     - No expiration checks based on certificate content.  Covered
>       by TLSA RRset's RRSIG expiration time.	[ Still under discussion. ]
>     - No purpose checks based on extended key usage.  Covered by
>       TLSA RRtype.	[ Still under discussion. ]
> [ ... ]
> Of the two "Still under discussion" fields, the expiration is by
> far the most important for the operational success of DANE.  By
> far the most common problem is expired certificates, and with
> DANE-EE(3), we have an opportunity to eliminate this problem.
> There is no more expiration, rather TLSA records are withdrawn from
> DNS by the server operator once the certificate is no longer
> appropriate (for whatever reason).  

So please think about this issue before the Thursday dane session,
and/or indicate your views on the list.

Related to this is the following observation:

    With "IN TLSA DANE-TA(2) SPKI(1) ..." records, the end entity
    server is free to modify any field in the TA certificate other
    than its subject name, its public key and fields constrained
    by the authority key identifier of the immediate child of the
    TA in the chain.  Since the end entity is then free to modify
    the TA certificate (but anything below it), should/may the
    content of such a TA certificate be mostly ignored?

In other words, should/may "IN TLSA 2 1 ?" be treated differently
from "IN TLSA 2 0 ?" with respect to the handling of the TA
certificate content, beyond the obvious difference of using either
the public key only, or the whole certificate to match the TLSA

For example, Postfix effectively ignores everything in the TA
certificate other than the public key with "IN TLSA 2 1 1" (after
all the TLSA record told us to trust the public key), but not with
"IN TLSA 2 0 1".

Since it looks like workable DANE support will be in OpenSSL 1.0.2
(in beta, to be released "soon"), now is a good time to settle
these questions.

There are two slides in the SMTP + OPS talk for London on DANE-EE(3)
and DANE-TA(2) semantics.