Re: [dane] DANE Client Authentication draft updated

"John Levine" <> Wed, 13 January 2016 01:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7A3011B2AA8 for <>; Tue, 12 Jan 2016 17:32:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.863
X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 1KvCeQRp82xv for <>; Tue, 12 Jan 2016 17:32:16 -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 237421B2B51 for <>; Tue, 12 Jan 2016 17:32:16 -0800 (PST)
Received: (qmail 36201 invoked from network); 13 Jan 2016 01:32:14 -0000
Received: from unknown ( by with QMQP; 13 Jan 2016 01:32:14 -0000
Date: 13 Jan 2016 01:31:52 -0000
Message-ID: <20160113013152.54184.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] 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 01:32:17 -0000

>On the "_smtp-client" label choice, I had originally used just "_smtp", but
>a colleague more plugged into IANA service name registration procedures
>advised me that I should choose a different client specific label. The
>"_smtp" label is a server side label with an associated server side port,
>and that reusing that label for a client identifier would elicit objections.

Yes, no kidding.

In the DNS, service names only appear as subnames of transport names.
So one possibility would be to register smtp-client as a service name,
so the DNS label would be _smtp-client._tcp.whatever.example.

On the other hand, these certificates aren't identifying services,
they're identifying clients, and unless I misunderstand, it should be
equally useful to identify clients for POP, IMAP, submission, and
anything else that can do TLS.  The list of service names already has
a fair number of client names, with the naming utterly inconsistent,
some with a trailing c, some with trailing "client", trailing
"-client", trailing "-cl", and a few just random acronyms.

To minimize the chaos I'd suggest registering a psedudo-service name
"client", always used with the actual service name as its subname.
So for my SMTP, POP, IMAP, and SUBMIT clients, the names would be


I suppose you could use the port number like RFC 6698 does but that
seems wrong since the server picks the port number.  If a SRV record
says that the server is, say, running pop3s on port 1234, the client
is still doing pop3s and can't rename its TLSA record on the fly.

Registering the service name is easy, just a few paragraphs in the
IANA considerations section.