Re: [dane] namespace management, DANE Client Authentication draft updated

Viktor Dukhovni <> Wed, 13 January 2016 18:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9EAE31B3061 for <>; Wed, 13 Jan 2016 10:14:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id adadLZBYeYt2 for <>; Wed, 13 Jan 2016 10:14:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 743CF1B3065 for <>; Wed, 13 Jan 2016 10:14:29 -0800 (PST)
Received: by (Postfix, from userid 1034) id 57C82284E5C; Wed, 13 Jan 2016 18:14:28 +0000 (UTC)
Date: Wed, 13 Jan 2016 18:14:28 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <20160113163235.65470.qmail@ary.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160113163235.65470.qmail@ary.lan>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Subject: Re: [dane] namespace management, DANE Client Authentication draft updated
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: Wed, 13 Jan 2016 18:14:30 -0000

On Wed, Jan 13, 2016 at 04:32:35PM -0000, John Levine wrote:

> >RRtype is sufficient for collision avoidance, I don?t think we gain
> >any practical benefit by adding the other labels.
> Oh, OK.  How about inventing a TLSACLIENT RRtype and use no prefix
> labels at all?
> I don't think that's a very good idea, but I'd be interested to hear
> if other people agree, and if so, why.

Well, we still a service-specific prefix, because we're signalling
the public keys for clients of a particular service on a particular
network node.  Clients for different services may well have different

The main argument that supports more than just a single service
prefix (if those are actually prone to collisions with various
other common prefixes like _spf, _dkim, ...) is that CNAMES are
quite useful with TLSA RRs when the payload is a trust-anchor digest
that should just be and managed in one place.

Thus if we really believe that there's a collision problem on just
the prefixed names, so that potential application client prefixes
(of the form suggested in the draft) already have existing non-TLSA
records, then it would be better to have just one additional label:

    _service._client.node.example. IN TLSA ...

So that one can create CNAME records:

    _service._client.node.example. IN CNAME _dane.example.

I still don't see any use for _tcp/_udp in there.