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

"John Levine" <johnl@taugh.com> Wed, 13 January 2016 05:41 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56771B2DA9 for <dane@ietfa.amsl.com>; Tue, 12 Jan 2016 21:41:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.863
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FldTGd_Q_Wev for <dane@ietfa.amsl.com>; Tue, 12 Jan 2016 21:41:33 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCEC1B2DA8 for <dane@ietf.org>; Tue, 12 Jan 2016 21:41:32 -0800 (PST)
Received: (qmail 71266 invoked from network); 13 Jan 2016 05:41:31 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 13 Jan 2016 05:41:31 -0000
Date: 13 Jan 2016 05:41:09 -0000
Message-ID: <20160113054109.54762.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dane@ietf.org
In-Reply-To: <CAHPuVdVAV8zny6OTx0HAvWrTKG7-EJa-xDM6cm72Z=aq-a+GzA@mail.gmail.com>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/rae-bV_f1sDX5BhEiimntegP7Cg>
Subject: Re: [dane] namespace management, DANE Client Authentication draft updated
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jan 2016 05:41:33 -0000

>Also recall that the proposed owner name is: _service.[client-domain-name].
>So a zone operator can define client domain name structures in a way that
>can address any namespace collision issues they wish to avoid. Presumably,
>an "_spf.device1.dept.example.com" TXT record would be about SPF rules
>pertaining to device1.dept.example.com, so there is likely not an issue with
>it co-existing with a client TLSA record at that same name.

I admire the faith you have in DNS operators, but find it baffling.
For a lot of the ones I know, their heads would explode at having to
mix TXT SPF records for the incoming mail and TLSA for the outgoing
mail at the same names in the same zone files.  They'd probably try
to kludge it with CNAME and break everything.

We already have a managed service namespace, which you can use with
trivial ease as _<service>._client._tcp.<domain>.  But I'm hearing no,
to save 12 characters in the domain name, and 12 lines of code in the
clients, we'll tell people to make up random prefixed names and when
the collisions inevitably happen, it won't be our problem.

R's,
John