Re: [dane] Digest Algorithm Agility discussion

Viktor Dukhovni <viktor1dane@dukhovni.org> Mon, 17 March 2014 22:53 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 5F3C41A0646 for <dane@ietfa.amsl.com>; Mon, 17 Mar 2014 15:53:40 -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 Y-nHo1e4jwLO for <dane@ietfa.amsl.com>; Mon, 17 Mar 2014 15:53:38 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 068091A01D7 for <dane@ietf.org>; Mon, 17 Mar 2014 15:53:37 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3894C2AB275; Mon, 17 Mar 2014 22:53:29 +0000 (UTC)
Date: Mon, 17 Mar 2014 22:53:29 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140317225329.GK24183@mournblade.imrryr.org>
References: <alpine.LFD.2.10.1403171440540.32251@bofh.nohats.ca> <20140317222320.443521AC59@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20140317222320.443521AC59@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/DxtzqXf1aB97xvHqzW6tddcB2c8
Subject: Re: [dane] Digest Algorithm Agility discussion
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: Mon, 17 Mar 2014 22:53:40 -0000

On Mon, Mar 17, 2014 at 11:23:20PM +0100, Martin Rex wrote:

> DANE does not have any "tarnished" hash algorithms.

Not yet.  The point of algorithm agility is to plan for the future.
Yes, it is currently difficult to imagine practical weaknesses in
SHA2-256, but time marches on.

> DANE does not allow SHA1 at all and needs SHA-256 as a minimum.

Yes.

> The weakest "link" is therefore the hash that is used by DNSSEC
> for the digital signature of the RRSET, which currently is SHA-1.

My zones are signed, or are about to be signed with algorithm 8,
RSASHA256.

> As long as DNSSEC does not require "stronger than SHA-256", it will
> be pure bike-shedding to prefer a SHA-512 TLSA record over a SHA-256 one.

We're specifying an agility algorithm.  Nobody has to publish
SHA2-512 digests.  Only SHA2-256 is mandatory at this time.  When
SHA2-512 is published, it may as well be used in preference to
SHA2-256.

Getting the specification right from the start avoids problems
later.

> And you probably do not want to hold your breath until DNSSEC has
> overcome SHA-1 based signatures.

There are existing zones that are signed with RSA, NSEC3, SHA256.

> The notion that hashes allowed by DANE can be ordered by strength/weakness
> is also wrong.

Nobody is suggesting ordering by the 8-bit mtype ordinal or mere
hash length.  The ordering is to be based on client-defined preference
for the underlying digest algorithms.

> In the future, hashes with the same output size might get a codepoint
> assigned and used, and some of them might not be implemented by all DANE
> clients.  

That's fine.  Servers can publish all mandatory to implement
algorithms, plus any others of their choice.

> Usage of SHA-512/256 over SHA-256 is not motivated by algorithm strength
> concerns, but rather by raw hash throughput considerations on 64-bit
> platforms.

And yet SHA2-512 likely has (absurdly) greater collision resistance
than SHA2-256.  Right now both are far out of reach of practical
attacks.  This may not always be the case, and, especially when
servers introduce various other hashes, clients may want to
use preferred digests.

I am not proposing anything particularly radical.  It is a fairly
obvious and conservative proposal.  "Negotiate" (pick from server's
menu of choices) an optimal digest algorithm and use only that one
and not the rest.

The objections are a bit surprising.  (I too would like to believe
that SHA2-256 will never be compromised, but it seems prudent to
plan for the worst).

To turn this around, why should clients run through all of the
server's published digests by default, when any one should be
enough?  Since servers don't know which algorithms clients disable
by local policy, it is a mistake to publish an object's digest with
only a subset of the algorithms used to publish other objects.

-- 
	Viktor.