Re: [dane] Digest Algorithm Agility discussion

Viktor Dukhovni <> Mon, 17 March 2014 18:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E33581A0449 for <>; Mon, 17 Mar 2014 11:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3YHOedZso5lG for <>; Mon, 17 Mar 2014 11:22:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1B0B41A042D for <>; Mon, 17 Mar 2014 11:22:28 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 18A9D2AB19D; Mon, 17 Mar 2014 18:22:19 +0000 (UTC)
Date: Mon, 17 Mar 2014 18:22:19 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
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 18:22:31 -0000

On Mon, Mar 17, 2014 at 11:14:32AM -0700, Paul Hoffman wrote:

> > There is no text in 6698 that even approximately suggests that clients
> > get to use only the records with the strongest (local criteria) digest.
> In Section 4.1:
>    o  A TLSA RRSet whose DNSSEC validation state is secure MUST be used
>       as a certificate association for TLS unless a local policy would
>       prohibit the use of the specific certificate association in the
>       secure TLSA RRSet.

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).  My proposal modifies the pseudo-code
to loop over only those records (for each usage/selector) with the
strongest digest plus any records with matching type 0.

The key difference is the lifecycle of a tarnished digest.  With
6698, it is trusted until the moment it is dropped.  With the new
proposal it gradually fades out.  I think the fading out part is
an important feature.  It makes it possible to be secure with
servers that publish strong RRs even while accepting weak digests
from servers that don't.