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

Viktor Dukhovni <> Thu, 14 January 2016 01:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B43111AD0C5 for <>; Wed, 13 Jan 2016 17:19:15 -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 py1_GCp7bgRq for <>; Wed, 13 Jan 2016 17:19:14 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 51F241AD0C3 for <>; Wed, 13 Jan 2016 17:19:14 -0800 (PST)
Received: from vpro.lan ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4F4A2284809 for <>; Thu, 14 Jan 2016 01:19:13 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Viktor Dukhovni <>
In-Reply-To: <20160114010138.66774.qmail@ary.lan>
Date: Wed, 13 Jan 2016 20:19:12 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <20160114010138.66774.qmail@ary.lan>
X-Mailer: Apple Mail (2.3112)
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: Thu, 14 Jan 2016 01:19:15 -0000

> On Jan 13, 2016, at 8:01 PM, John Levine <> wrote:
>> Because the client prefix-label a service *name*, so so the port
>> collision issue goes away.  We should not cargo-cult designs,
>> the rationale has to carry over logically, and false analogies
>> need to be avoided.
> One man's cargo cult is another man's namespace management.  Every
> existing use of _<service> names is behind a _<proto> name, and there
> seems to me considerable merit to keep it that way, at the trivial
> cost of a possibly uninteresting _tcp or _udp in the name.  If the
> extra five bytes is an issue, I suppose we could use _c rather than
> _client for the client tag.
> While saving five characters was a big deal when I was programming
> PDP-8's almost 50 years ago, I don't get it now.

This forces clients that use both TCP and UDP to publish their TLSA
records twice (or better publish one as a CNAME for the other, or
make both CNAMEs to a third thing).  Is this really worth it?

Folks are having a hard enough time publishing correct TLSA records,
and remembering to change all the copies.