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

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 13 January 2016 18:14 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 9EAE31B3061 for <dane@ietfa.amsl.com>; Wed, 13 Jan 2016 10:14:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 adadLZBYeYt2 for <dane@ietfa.amsl.com>; Wed, 13 Jan 2016 10:14:29 -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 743CF1B3065 for <dane@ietf.org>; Wed, 13 Jan 2016 10:14:29 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 57C82284E5C; Wed, 13 Jan 2016 18:14:28 +0000 (UTC)
Date: Wed, 13 Jan 2016 18:14:28 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20160113181428.GN18704@mournblade.imrryr.org>
References: <D2BBCA86.21C7D%gwiley@verisign.com> <20160113163235.65470.qmail@ary.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160113163235.65470.qmail@ary.lan>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/sHnIPYzcuALjK9Yy4lNw_CcsdNc>
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 18:14:30 -0000

On Wed, Jan 13, 2016 at 04:32:35PM -0000, John Levine wrote:

> >RRtype is sufficient for collision avoidance, I don?t think we gain
> >any practical benefit by adding the other labels.
> 
> Oh, OK.  How about inventing a TLSACLIENT RRtype and use no prefix
> labels at all?
> 
> I don't think that's a very good idea, but I'd be interested to hear
> if other people agree, and if so, why.

Well, we still a service-specific prefix, because we're signalling
the public keys for clients of a particular service on a particular
network node.  Clients for different services may well have different
certs/keys.

The main argument that supports more than just a single service
prefix (if those are actually prone to collisions with various
other common prefixes like _spf, _dkim, ...) is that CNAMES are
quite useful with TLSA RRs when the payload is a trust-anchor digest
that should just be and managed in one place.

Thus if we really believe that there's a collision problem on just
the prefixed names, so that potential application client prefixes
(of the form suggested in the draft) already have existing non-TLSA
records, then it would be better to have just one additional label:

    _service._client.node.example. IN TLSA ...

So that one can create CNAME records:

    _service._client.node.example. IN CNAME _dane.example.

I still don't see any use for _tcp/_udp in there.

-- 
	Viktor.