Re: [dane] Calling the naming issue...

Guido Witmond <> Tue, 10 December 2013 22:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CC7D81AE08B for <>; Tue, 10 Dec 2013 14:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.194
X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cnux2pEHd07a for <>; Tue, 10 Dec 2013 14:10:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 683631AE053 for <>; Tue, 10 Dec 2013 14:10:45 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTP id 77D02CA79E for <>; Tue, 10 Dec 2013 22:10:35 +0000 (UTC)
Message-ID: <>
Date: Tue, 10 Dec 2013 23:10:29 +0100
From: Guido Witmond <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="----enig2QDBTQJLLPFQCNJVPSPFC"
Subject: Re: [dane] Calling the naming issue...
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Dec 2013 22:10:49 -0000

On 12/10/13 22:13, Richard Barnes wrote:
> I'm a little confused, since I see a message from Warren on 6 Dec saying
> that the call would be extended until tomorrow.  I admit that I have not
> been following this discussion closely, though.
> In case the window for comments / proposals is still open, my only
> insight here is that usages 0/1 are very much like the "pinning" work
> being done in draft-ietf-websec-key-pinning, so it might be helpful to
> re-use that term here.  For 2/3, it seems like people I've talked to
> understand the verbs "assert" (since that's what the domain holder is
> doing) or "trust" (since that's what the recipient is being asked to do).
>         0 - PIN-CA
>         1 - PIN-EE
>         2 - ASSERT-CA or TRUST-CA
>         3 - ASSERT-EE or TRUST-EE
> So that's my favorite color for the bike shed.  

To add my own color:

DANE can only specify *intent*. Intent of the domain owner what they
choose for their certificate source.

Without *verification* that intent is worthless.

1. The owner of the domain must regularly validate that their chosen
DNS-registrar still publishes the owners' intent, preferably with
something like Perspectives that registers and remembers historic

2. People doing a lookup for the current value of TLSA records should
validate these against the Perspectives history. When it matches, it's
OK. When there is a mismatch, there is a problem. The only solution for
the resolver is to fail fast and for the user to twitter about it. Make
it public and let the community resolve the problem. It could be lousy
DNS-registrar, the domain owner looks for a better one. It could be a
MitM-device, the end user learns of its existence.

In short, without *verification* DANE doesn't do so much. With
verification, it's a big leap ahead. CT protects in the 0/1 cases,
Perspectives in the 2/3 cases.

IMHO, the naming should reflect the source of the certificate:
0: Global trusted CA;
1: End certificate in a chain from a Global trusted CA;
2: My own CA;  ( from the perspective of the domain owner)
3: My own Certificate; (same perspective)

Cheers, Guido.