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

"John Levine" <> Wed, 13 January 2016 05:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 507321B2D8E for <>; Tue, 12 Jan 2016 21:30:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 04_54hAqRz0m for <>; Tue, 12 Jan 2016 21:30:11 -0800 (PST)
Received: from ( [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0453E1B2D8D for <>; Tue, 12 Jan 2016 21:30:10 -0800 (PST)
Received: (qmail 69636 invoked from network); 13 Jan 2016 05:30:09 -0000
Received: from unknown ( by with QMQP; 13 Jan 2016 05:30:09 -0000
Date: 13 Jan 2016 05:29:47 -0000
Message-ID: <20160113052947.54721.qmail@ary.lan>
From: "John Levine" <>
In-Reply-To: <>
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
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:30:12 -0000

In article <> you write:
>> On Jan 12, 2016, at 9:32 PM, John R Levine <> wrote:
>> They've appeared under transport names for the past 15 years, which means that people have expectations
>about how they're used which I would not casually ignore.
>And yet client identities are not really transport-specific.

Hi, Viktor.  As I said in the message to which you just responded, two
paragraphs below the one you quoted:

 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.

>> There are a lot of other prefixed names floating around the DNS.  If someone attempted to use a client
>name like _spf or _sip or _domainkey or _dmarc or _adsp or _vouch they and their users would experience
>an eternity of pain from name collisions.
>Only if there are TLSA records for those names.

Well, OK.  How much do you want to bet that there won't be, ever, for
those names and for anything else for which someone uses a prefixed
name?  We can easily avoid this problem now, or painfully sort of work
around it in the future.  I don't see that as a hard choice.