Re: [dane] Digest algorithm agility (possible discussion topic for: Informal lunch meeting in Vancouver on Thursday)

Matt McCutchen <> Wed, 06 November 2013 01:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F47221E818E for <>; Tue, 5 Nov 2013 17:42:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MOWkLw8d10Wh for <>; Tue, 5 Nov 2013 17:42:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 061F721E81A9 for <>; Tue, 5 Nov 2013 17:40:47 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 2E57C28006C for <>; Tue, 5 Nov 2013 17:40:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= message-id:subject:from:to:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; s=; bh=bByf3WTfdWyxdNUxQtnyulNOSTA=; b=rfWdtXpQ4H zPFPAyYpfMEZLA/0lZx9ikAojo0kx24Xd1szmh8DD5rYjKrAQxZbpO9AwDc5KuV4 yWKxvJr28eCijrBmujlJo0RolE0Egj4FsFl50YFtMyn6DsnynDoJundRZaH/Utgj hRBhguRbiz4bTanvpx5mPn9T41YU6tiew=
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 0EB81280063 for <>; Tue, 5 Nov 2013 17:40:19 -0800 (PST)
Message-ID: <1383702043.26498.20.camel@localhost>
From: Matt McCutchen <>
Date: Tue, 05 Nov 2013 17:40:43 -0800
In-Reply-To: <>
References: <> <>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.2
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [dane] Digest algorithm agility (possible discussion topic for: Informal lunch meeting in Vancouver on Thursday)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Nov 2013 01:42:19 -0000

On Mon, 2013-11-04 at 22:32 +0000, Viktor Dukhovni wrote:
> Though I am not attending the Vancouver IETF meeting, I am interested
> in feedback on the below DANE-related issue:
>     - Suppose some day we discover that SHA256 is flawed and is
>       subject to effective second-preimage attacks.
>     - Suppose that hypothetically SHA512 remains secure.
>     - How would clients and servers gracefully cut-over to only
>       use SHA512 and avoid SHA256?
> My proposal is as follows:
> When a TLSA RRset contains multiple RRs of the form:
>         _<port> IN TLSA <U> <S> <M> <D>
> with the same values of "U" and "S" but different values of the
> matching type, a client MAY ignore a "weaker" matching type
> (deprecated digest algorithm) when a "stronger" matching type for
> the same usage and selector is present.  Which matching types are
> considered "weaker" is generally at the client's discretion.

>     - TLSA records that specify multiple certificates or public
>       keys for a single (U,S) combination (e.g. multiple trust
>       anchors, or multiple EE certificates during key roll-over)
>       MUST use the same set of matching types for all of them!
>       Otherwise, clients may fail to support one of the desired
>       certificates, when they choose to support only the RRs with
>       the strongest matching type.

I.e., the same solution that is de facto used by DNSSEC DS records

I believe in the need for algorithm agility and proposed three possible
solutions including the above during the original design process
(, but got no