Re: [dane] WGLC: DANE-SRV (Abstract and introduction feedback)

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 03 December 2014 05:19 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 305AB1A008C for <dane@ietfa.amsl.com>; Tue, 2 Dec 2014 21:19:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 s0PlqVov0b4Z for <dane@ietfa.amsl.com>; Tue, 2 Dec 2014 21:19:50 -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 4C6681A008B for <dane@ietf.org>; Tue, 2 Dec 2014 21:19:50 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 56BDE282D5F; Wed, 3 Dec 2014 05:19:49 +0000 (UTC)
Date: Wed, 03 Dec 2014 05:19:49 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20141203051949.GF285@mournblade.imrryr.org>
References: <20141201013357.GF285@mournblade.imrryr.org> <547BC8F9.1070605@andyet.net> <20141201033009.GI285@mournblade.imrryr.org> <1417559579751.81339@godaddy.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1417559579751.81339@godaddy.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/bm9RoYCqfNf5aH69IGAEGdKwXBk
Subject: Re: [dane] WGLC: DANE-SRV (Abstract and introduction feedback)
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: <http://www.ietf.org/mail-archive/web/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, 03 Dec 2014 05:19:52 -0000

On Tue, Dec 02, 2014 at 10:33:00PM +0000, Michael J. Sheldon wrote:

> >On Sun, Nov 30, 2014 at 06:48:41PM -0700, Peter Saint-Andre - &yet wrote:
> >General comment:
> >
> >    The draft frequently talks about "hostnames", where what is
> >    really meant is a transport endpoint (port, transport protocol,
> >    host).  With PKIX-EE or DANE-EE certificate usages, TLSA records
> >    are more precise than the Web PKI and can associate different,
> >    non-interchangeable key material with distinct services on a
> >    single host.  So in many places I will be suggesting replacing
> >    statements about "hostnames" with statements about "transport
> >    endpoints".
> 
> From a DNS point of view, this may be more confusing. DNS does
> not distinguish between different types of record owners. If you
> put it in there, it just became a domain name, which most people
> will refer to as a host name if it is not at the apex.

You misunderstood my point.  The issue is not about DNS owner names.
The issue is that SRV records designate a (port, hostname) pair,
not just a hostname, and the input to TLSA lookup is a (port,
protocol, hostname) triple not just a hostname.

> Not saying it's not a good distinction, it is, but I would tread
> lightly where you are talking about the actual TLSA record owner
> name.

I am not talking about DNS owner names at all.  The association in
DANE TLSA is between a transport endpoint and its key material.
The fact that we construct some DNS name to find this is secondary,
(and in fact that owner name is NOT a hostname due to the various
underscores, but that's not important).

Since SRV also produces lists of transport endpoints, and unlike
the Web PKI, the certificates in DANE TLSA can (and often should)
be different for different services on the same machine, the
discussion is much clearer if we don't gloss over the fact that
the TLSA binding is NOT a hostname->key binding.

I hope to post further feedback on Thursday evening.  It would be
useful if possible to get additional initial reaction to the proposed
changes in the abstract and introduction.

-- 
	Viktor.