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

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 18 March 2014 18:14 UTC

Return-Path: <paul.hoffman@vpnc.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 8BA821A0768 for <dane@ietfa.amsl.com>; Tue, 18 Mar 2014 11:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 jw105Xtn5wBo for <dane@ietfa.amsl.com>; Tue, 18 Mar 2014 11:14:05 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 62F7F1A0769 for <dane@ietf.org>; Tue, 18 Mar 2014 11:09:45 -0700 (PDT)
Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2II9ZtY087328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <dane@ietf.org>; Tue, 18 Mar 2014 11:09:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <20140318143759.GP24183@mournblade.imrryr.org>
Date: Tue, 18 Mar 2014 11:09:31 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <48DE266C-3800-4428-A9E5-F0A732D35D9D@vpnc.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> <20140318143759.GP24183@mournblade.imrryr.org>
To: dane@ietf.org
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/gbjlNGeHoYgFfWAOjTliohUyTho
Subject: Re: [dane] Digest Algorithm Agility discussion (checkpoint)
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: <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 18:14:11 -0000

On Mar 18, 2014, at 7:37 AM, Viktor Dukhovni <viktor1dane@dukhovni.org>; wrote:

> 
> 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.

This discussion keeps getting into the "we're the Internet Police" realm. First it is "we know which hash algorithms are too weak", and now it is "operators must do this action or else different clients will behave differently".

If an operator wants to use a particular hash algorithm *for any reason*, we should not stop them.

>    - 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.

It would only have that benefit if there was agreement from above on what "weaker" was and whether we should force people to limit themselves to our algorithms.

> 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.  

Exactly right.

> 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.

This is insane. You are creating operational failure cases for servers for no benefit until one of the hash algorithms has a significant weakness. Even then, the damage you are proposing quite outweighs the chance of any real damage from the use of a weakened hash. Hashes weaken very slowly, and there is plenty of time to alert people to use stronger hashes.

> 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.

They do: it's called local policy.

--Paul Hoffman