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

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 13 January 2016 07:04 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 9D88C1A8A8F for <dane@ietfa.amsl.com>; Tue, 12 Jan 2016 23:04:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.414
X-Spam-Level:
X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 X7k8M7WqhbaA for <dane@ietfa.amsl.com>; Tue, 12 Jan 2016 23:04:41 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEBC91A894E for <dane@ietf.org>; Tue, 12 Jan 2016 23:04:41 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A7523284AED; Wed, 13 Jan 2016 07:04:40 +0000 (UTC)
Date: Wed, 13 Jan 2016 07:04:40 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20160113070440.GL18704@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m3ziwa8sww.fsf@carbon.jhcloos.org> <20160113064221.54965.qmail@ary.lan>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/PtAgsyjltT1m3felkZcWdyV6NGc>
Subject: Re: [dane] namespace management, DANE Client Authentication draft updated
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
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 07:04:43 -0000

On Wed, Jan 13, 2016 at 06:42:21AM -0000, John Levine wrote:

> > ...  But what's the real benefit to all this?
> 
> You're avoiding name collisions down the road.

Please don't get me wrong, I'm not zealous about this, just don't
yet see any value in the additional labels, and surely we should
add them for a good reason.  I would expect the RRtype to provide
all the collision avoidance that's required.  Plus the fact that
these are intended to be host-specific records, while, the various
proposed example collisions are generally published at the parent
domain of the various hosts.

If we have to insert "_client" and that's the WG consensus, fine,
just extra bits on the wire.  As for "_tcp", that is really just
excess baggage.  Once we move move away from port numbers to
application names the transport protocol to disambiguate numeric
ports really does not seem at all helpful.

Anyone voting for application OIDs to avoid collisions?  The OID
space is plausibly in better shape than the flat IANA service name
registry...

> >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.
> 
> Surely we don't have to review the difference between name components
> and zone cuts. Nobody has proposed putting a new zone under each host
> name.

I guess James is "nobody". :-)

On Tue, Jan 12, 2016 at 03:05:51PM -0500, James Cloos wrote:
>
> For draft-huque-dane-client-cert I'd still prefer RR names like:
> 
>  _smtp._client.example
> 
> for the cert provided by an smtp client which HELO/EHLOs as example.
> And similarly for other protocols.  Rather than things like _smtp-client.
> 
> Putting all of the client TLSAs under a single label allows (but
> obviously does not require) them to be in their own zone.

-- 
	Viktor.