Re: [dane] Digest Algorithm Agility discussion (checkpoint)

Viktor Dukhovni <viktor1dane@dukhovni.org> Tue, 18 March 2014 14:38 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 17B221A04BC for <dane@ietfa.amsl.com>; Tue, 18 Mar 2014 07:38:10 -0700 (PDT)
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 Mzrlrw3Qk67R for <dane@ietfa.amsl.com>; Tue, 18 Mar 2014 07:38:08 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1516D1A04CD for <dane@ietf.org>; Tue, 18 Mar 2014 07:38:08 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 70CB82AB22D; Tue, 18 Mar 2014 14:37:59 +0000 (UTC)
Date: Tue, 18 Mar 2014 14:37:59 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140318143759.GP24183@mournblade.imrryr.org>
References: <alpine.LFD.2.10.1403171440540.32251@bofh.nohats.ca> <20140317222320.443521AC59@ld9781.wdf.sap.corp> <20140317225329.GK24183@mournblade.imrryr.org> <20140318112647.885B21190C03@rock.dv.isc.org> <20140318141356.GO24183@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140318141356.GO24183@mournblade.imrryr.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/llkWNPAOZTpE-2SjBybOdT_ACoQ
Subject: Re: [dane] Digest Algorithm Agility discussion (checkpoint)
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: Tue, 18 Mar 2014 14:38:10 -0000

Thanks to everyone who contributed to this point.  My conclusions
so far:

    - Since "local policy" may exclude an arbitrary subset of the
      digest algorithms from consideration, whether the digest
      algorithm employed by clients is as I suggest, or not, server
      operators MUST apply the SAME set of digests to all objects
      published in a TLSA RRset, since otherwise the "visibility"
      of objects in the RRset will be client dependent.

    - Given the above clients either MAY or SHOULD apply the
      algorithm I propose, it provides incremental benefit before
      weaker algorithms are dropped, and reduces risks to servers
      that publish weaker algorithms.

      For example, with opportunistic TLS, client and server
      implementations can safely leave weaker cipher-suites at a
      low priority on their cipher-lists, because these will not be
      chosen when stronger options are available.  When nothing
      better is available, these are at least better than cleartext.

If "local policy" per 6698, includes the possibility of "adaptive
local policy" that depends on the server's TLSA RRset content, then
my proposal is already an implicit MAY per 6698.  I'd like to propose
to elevate it to a SHOULD, while emphasizing the MUST for the server
to publish cross-product TLSA RRsets when employing multiple digests.

Reminder: the proposal is that clients SHOULD apply some local
ranking to the digest algorithms, and only use those records for
each (usage, selector) combination that either have a matching type
of Full(0) or have the best ranking among all digests used with
that (usage, selector).  Clients SHOULD have a way to completely
disable algorithms.

-- 
	Viktor.