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

Viktor Dukhovni <> Wed, 13 January 2016 05:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 662B61A0390 for <>; Tue, 12 Jan 2016 21:53:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pk7ltCMsRjVp for <>; Tue, 12 Jan 2016 21:53:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C19C1A0389 for <>; Tue, 12 Jan 2016 21:53:23 -0800 (PST)
Received: by (Postfix, from userid 1034) id 9919E284AED; Wed, 13 Jan 2016 05:53:22 +0000 (UTC)
Date: Wed, 13 Jan 2016 05:53:22 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <20160113052947.54721.qmail@ary.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160113052947.54721.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 05:53:25 -0000

On Wed, Jan 13, 2016 at 05:29:47AM -0000, John Levine wrote:

>  It has very little to do with distinct transport protocols, and
>  everything to do with avoiding name collisions.  Nobody runs POP or
>  IMAP over UDP, but the SRV names are still _pop3._tcp and _imap._tcp.

That's because SRV records are a generic (somewhat over-engineered)
construction, and we're stuck with separate:

	_kerberos._udp.realm.example. IN SRV 100 0 88 kdc1.example.
	_kerberos._tcp.realm.example. IN SRV 100 0 88 kdc1.example.

with the only benefit of this separation being the ability to
discover that a given realm has no UDP-based or has no TCP-based
KDCs.  None of this is especially relevant for clients.

So we can keep the client TLSA record query name simple with:

    ; TLSA RRtype sufficient to distinguish this from all
    ; other uses of the name, and any collisions with server
    ; names with look like _port._proto.server.example.
    ; IN TLSA 3 1 1 ...

or we inject additional labels, making the name further removed
from identifying a DANE application at a given DNS node: IN TLSA 3 1 1 ...

because _client might be used in non-dane contexts, and we want to
distinguish TCP from UDP, ...  But what's the real benefit to all
this?  We're publishing TLSA records for "application" on "box.example",
is any  of the other baggage really helpful?

With enough such labels, we don't need a TLSA RRtype, just use TXT,
and encode the data in JSON. IN TXT "{usage=3, selector=1, mtype=1, data=...}"

The point I'm trying to make is that given the base domain, an
application-specific initial _label, an the TLSA RRtype, we have
all the essential distinguishing identifiers and anything else is
baggage that needs justification.  

James makes a plausible point about _client as a way to carve out
a zone for clients, but because unlike SMIME/A or OPENPGPKEY the
base domain is here typically not a zone apex, but rather a specific
host, carving out a new zone under each host scales poorly.  And
this takes away the simplicity of an identity mapping between the
query domain and the corresponding SRV-ID.

So I while I am sympathetic to his argument, I don't think it holds
up in the end.

If we start injecting _proto, and various additional labels, I am
pretty we'd be overdoing the design.  There has be a good reason
for these, beyond superficial similarity to server use-cases that
are not actually analogous.