Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys

Viktor Dukhovni <viktor1dane@dukhovni.org> Fri, 30 May 2014 14:15 UTC

Return-Path: <viktor1dane@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 A8F201A08BD for <dane@ietfa.amsl.com>; Fri, 30 May 2014 07:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 DEG1SE7IzE-a for <dane@ietfa.amsl.com>; Fri, 30 May 2014 07:15:21 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4661A08F6 for <dane@ietf.org>; Fri, 30 May 2014 07:15:21 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D011D2AB137; Fri, 30 May 2014 14:15:16 +0000 (UTC)
Date: Fri, 30 May 2014 14:15:16 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140530141516.GR27883@mournblade.imrryr.org>
References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <201405300616.s4U6GwBT015849@new.toad.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <201405300616.s4U6GwBT015849@new.toad.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1KayKnPKq-oeWQIjtVCRF7yS-0k
Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys
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: Fri, 30 May 2014 14:15:22 -0000

On Thu, May 29, 2014 at 11:16:58PM -0700, John Gilmore wrote:

> Or, do you have an actual, substantive, technical issue with the
> proposed extension of the DANE TLSA records?

Turf wars aside, either the TLS extension document could document
the DANE implications (including the point about when it is safe
to signal "oob public key" when the client intends to use DANE
auth) or a new DANE draft gets to document the TLS implications
(including that same point).

So some overlap is unavoidable.  For example, the SMTP and OPS
drafts already talk about requiring "2 X Y" trust anchor certs in
server_certificate TLS messages, these are optional with PKIX.

My gut feeling is that since the issue applies only to clients for
which "oob" means "DANE", there should at least be a DANE WG document
that covers this perhaps among other topics.

Would it be a problem if this got covered consistently in multiple
documents?  From the perspective of an implementor it would be
helpful to see this covered in which-ever document I happened to
be reading when adding bare public key support.

-- 
	Viktor.