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

Viktor Dukhovni <viktor1dane@dukhovni.org> Tue, 18 March 2014 20:00 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 166BB1A02FB for <dane@ietfa.amsl.com>; Tue, 18 Mar 2014 13:00:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.414
X-Spam-Level:
X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486] 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 y5Qp92E_PGvf for <dane@ietfa.amsl.com>; Tue, 18 Mar 2014 13:00:16 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 398C91A0296 for <dane@ietf.org>; Tue, 18 Mar 2014 13:00:16 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D22ED2AAD62; Tue, 18 Mar 2014 20:00:04 +0000 (UTC)
Date: Tue, 18 Mar 2014 20:00:04 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140318200004.GU24183@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <034101cf42d0$dbf12b00$93d38100$@augustcellars.com> <48DE266C-3800-4428-A9E5-F0A732D35D9D@vpnc.org> <20140318192007.GA28214@mx1.yitter.info>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/4cG-QECJk7PBYHsAc5t6okgePm4
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 20:00:18 -0000

On Tue, Mar 18, 2014 at 03:20:07PM -0400, Andrew Sullivan wrote:

> I would say this instead as, "We will not be able to stop them anyway,
> so we should focus on interoperability and maybe some sound advice,"
> but I know lots of people will disagree.

On Tue, Mar 18, 2014 at 11:09:31AM -0700, Paul Hoffman wrote:

> [ Lots of misinterpretation and inaccuracies about the proposed mechanism. ]
>
> 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.

On Tue, Mar 18, 2014 at 10:38:22AM -0700, Jim Schaad wrote:

> > Stop trying to over engineer this.
> 
> +1 - At any given time this is a binary choice.  The hash algorithm either
> is or is not acceptable.

I don't think I to need to restate the merits of the incremental
security as stronger digests are added before weaker ones are
disabled.

My sense is that regardless, there is not much enthusias for
negotiating a single digest based on what digests the server offers,
with the client choosing its most preferred one.

Is this an accurate summary of the group's consensus view?  Does
anyone want to defend the view of TLSA digests as a menu of options
from which the client can choose one?

If not, I will drop the digest agility portion of the SMTP draft.
In the OPs draft we can encourage server operators (SHOULD) to
apply all digests equally to all objects, because that's more robust
in the face of local policy, and results when this is not done may
not be what the operator wanted.

Anyone else?

-- 
	Viktor.