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

Viktor Dukhovni <viktor1dane@dukhovni.org> Fri, 30 May 2014 19:28 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 6FFC61A6FD0 for <dane@ietfa.amsl.com>; Fri, 30 May 2014 12:28:46 -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 ditmPKsGr5IK for <dane@ietfa.amsl.com>; Fri, 30 May 2014 12:28:44 -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 D43021A0A2F for <dane@ietf.org>; Fri, 30 May 2014 12:28:44 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 139572AB117; Fri, 30 May 2014 19:28:40 +0000 (UTC)
Date: Fri, 30 May 2014 19:28:40 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140530192840.GC27883@mournblade.imrryr.org>
References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> <alpine.LFD.2.10.1405291257210.14277@bofh.nohats.ca> <20140529180356.GL27883@mournblade.imrryr.org> <m3a99zgkdk.fsf@carbon.jhcloos.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <m3a99zgkdk.fsf@carbon.jhcloos.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/c_0GfKqvAxPLEvdCBS4v5v_041U
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:28:46 -0000

On Fri, May 30, 2014 at 03:02:22PM -0400, James Cloos wrote:

> A 3 0 0 tlsa will work as well as a 3 1 x.  The client can pull the spki
> out on its own.

Not true.  When the server presents only the SPKI (no certificate
wrapped around it), the client cannot magically reconstruct the
enclosing certificate.

> It is not that *all* tlsas need to be limited just because the server
> supports the oob methods.  Rather, *at least one* of the published tlsas
> must be usable (3-0-0 or 3-1-x and secure in this case) and match.

Not true.  If the server's "3 1 x" RRs reflect only keys that were
active in the past, or only keys that will be active in the future,
while the currently active certificate key matches other TLSA RRs
((usage, selector) != (DANE-EE(3), SPKI(1)) then the client loses
if it negotiates "oob public key" and server only presents a leaf
SPKI instead of a leaf cert.

I wish folks would take a moment to think this through, it is not
that hard.  If you still don't see it, you've not thought about it
hard enough yet.

-- 
	Viktor.