Re: [dane] Digest Algorithm Agility discussion (Martin Rex) Mon, 17 March 2014 22:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3F0A31A0642 for <>; Mon, 17 Mar 2014 15:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wt32XKHDXIMl for <>; Mon, 17 Mar 2014 15:23:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A46571A063A for <>; Mon, 17 Mar 2014 15:23:38 -0700 (PDT)
Received: from by (26) with ESMTP id s2HMNKgf018594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Mar 2014 23:23:20 +0100 (MET)
In-Reply-To: <>
To: Paul Wouters <>
Date: Mon, 17 Mar 2014 23:23:20 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
X-SAP: out
Cc: dane WG list <>
Subject: Re: [dane] Digest Algorithm Agility discussion
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Mar 2014 22:23:40 -0000

Paul Wouters wrote:
> On Mon, 17 Mar 2014, Viktor Dukhovni wrote:
>> This is not "use strongest".  This is the opposite.  It forces the
>> use of tarnished, but still acceptable digests even when untarnished
>> digests are present.  The new proposal is to ignore all but the
>> strongest, even when the remainder would be usable.
>> Also the pseudo-code in the appendices loops over *all* "usable" TLSA
>> RRs (those not banned by 4.1).
> Okay, I understand your point now. The text in 6698 is indeed doing some
> half weird local policy client dictation that it should not have done.

DANE does not have any "tarnished" hash algorithms.

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

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

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.

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

The notion that hashes allowed by DANE can be ordered by strength/weakness
is also wrong.  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.  Think of hashes from the russian
GOST family of algorithms.  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.