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

"John Levine" <johnl@taugh.com> Thu, 14 January 2016 02:49 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 0A4C71B2AE5 for <dane@ietfa.amsl.com>; Wed, 13 Jan 2016 18:49:34 -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_40=-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 YzdvDbOa2L5F for <dane@ietfa.amsl.com>; Wed, 13 Jan 2016 18:49: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 30C4C1B2ADE for <dane@ietf.org>; Wed, 13 Jan 2016 18:49:33 -0800 (PST)
Received: (qmail 85429 invoked from network); 14 Jan 2016 02:49:32 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Jan 2016 02:49:32 -0000
Date: 14 Jan 2016 02:49:10 -0000
Message-ID: <20160114024910.67019.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dane@ietf.org
In-Reply-To: <9C1F4A0C-0E08-4F6E-BDB1-74E55CB4EF2A@dukhovni.org>
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/_5lnU5Gfjneg_j9TExC5gBBm6K4>
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: Thu, 14 Jan 2016 02:49:34 -0000

>This forces clients that use both TCP and UDP to publish their TLSA
>records twice (or better publish one as a CNAME for the other, or
>make both CNAMEs to a third thing).  Is this really worth it?

How much of a problem has it been for TLSA server records?  I honestly don't
know but I'd be surprised if the answer were other than "not much".  

Creating the certificate and turning that into the right hex for the
TLSA master record seems vastly harder than adding a CNAME which, if
you are right that nobody ever does anything different on TCP and UDP,
could be added mechanically.

R's,
John