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

Viktor Dukhovni <viktor1dane@dukhovni.org> Fri, 30 May 2014 19:03 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 2536C1A04A1 for <dane@ietfa.amsl.com>; Fri, 30 May 2014 12:03:27 -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 hWAboqLbm1dY for <dane@ietfa.amsl.com>; Fri, 30 May 2014 12:03:26 -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 CA9B41A01B5 for <dane@ietf.org>; Fri, 30 May 2014 12:03:25 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 321FE2AB117; Fri, 30 May 2014 19:03:20 +0000 (UTC)
Date: Fri, 30 May 2014 19:03:20 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140530190319.GB27883@mournblade.imrryr.org>
References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <201405300616.s4U6GwBT015849@new.toad.com> <20140530141516.GR27883@mournblade.imrryr.org> <alpine.LFD.2.10.1405301426520.21222@bofh.nohats.ca> <20140530184403.GA27883@mournblade.imrryr.org> <alpine.LFD.2.10.1405301445520.21222@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.10.1405301445520.21222@bofh.nohats.ca>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/jW3yYFat6a4N8vdHz0zcdE4bYf0
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 19:03:27 -0000

On Fri, May 30, 2014 at 02:50:17PM -0400, Paul Wouters wrote:

> >   * This is the obvious part of how to use "oob public key" with
> >     DANE, and need hardly be explained.  The non-obvious part is the
> >     need to only signal "oob public key" support in the client
> >     when server's TLSA RRs contain *only* "DANE-EE(3) SPKI(1) ?"
> >     records.
> 
> This is the third time you mention this and the third time I have to ask
> you why.

That is, the third time you've failed to understand. :-(

The context as stated before, is clients for which "oob" means DANE
auth, and the restriction is for that case only.

> Please
> try and explain why you are trying to add restrictions on the set of
> TLSA records to support "oob public key" (which can happen on its own,
> along with regular full cert support, with or without DANE)

Clients for which DANE auth is the authentication mechanism MUST
NOT exclude any "usable" TLSA RRs from the potential set of matching
records by negotiating "oob public key" which is only compatible
with "3 1 X".  The reason, as before, is that there is no a-priori
way to determine which subset of the TLSA RRs is sufficient to
authenticate the server.

-- 
	Viktor.