[dane] Digest Algorithm Agility discussion

Viktor Dukhovni <viktor1dane@dukhovni.org> Sat, 15 March 2014 05:17 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 4CC451A000E for <dane@ietfa.amsl.com>; Fri, 14 Mar 2014 22:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Q_oVoH0GfRIv for <dane@ietfa.amsl.com>; Fri, 14 Mar 2014 22:17:14 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org []) by ietfa.amsl.com (Postfix) with ESMTP id 2C9401A0002 for <dane@ietf.org>; Fri, 14 Mar 2014 22:17:13 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E08342AB22D; Sat, 15 Mar 2014 05:17:04 +0000 (UTC)
Date: Sat, 15 Mar 2014 05:17:04 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140315051704.GY21390@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/tTK1wXXuvGJH8plYbuOupl7_7_0
Subject: [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: Sat, 15 Mar 2014 05:17:16 -0000

The SMTP draft specifies a digest algorithm agility protocol for DANE.

In this thread it would be helpful to arrive at consensus around
the proposal, or a modified proposal if a better approach is
suggested.  Once that's settled, we can briefly touch on which document
is the right home for this protocol.


    * It should be possible for servers to publish TLSA records
      employing multiple digest algorithms allowing clients to
      choose the best mutually supported digest.

Important barrier:

    * When two or more distinct objects (multiple certificates or multiple
      public keys) are published in TLSA records with multiple
      digest algorithms, it is not possible based on the TLSA records
      alone to partition the records by object instance, combining
      related records that are merely different digests of the same
      underlying object.

    * What this means is that clients can't tell whether ignoring all
      the records for a given weaker digest does not result in
      leaving out some objects which are only present with that


     * The burden of making it safe to disregard records with deprecated or
       in any case less preferred digest algorithms is placed on the TLSA
       record publisher.

     * If for each given usage and selector, each published object that
       appears with a non-zero (i.e. a digest) matching type appears with
       the *same set* of digests as all other objects with that usage and
       selector, then it is definitely safe for clients to disregard all
       records except those with strongest (per client configuration)

     * The server MUST employ this approach to publishing its records.

     * The client SHOULD employ digest algorithm agility by ignoring
       all but the strongest non-zero digest for each usage/selector
       combination.  Note, records with matching type zero play no
       role in digest algorithm agility.

Open issue:

     * Suppose the server records are clearly in violation of the
       requirement, because the number of records for one of the
       digest algorithms is strictly greater than the (non-zero)
       number of records for some other algorithm.

       Should the client apply the agility algorithm anyway (server
       is to blame if this is not safe)?  Or should it avoid using
       digest agility in this case?

       Note, avoiding the algorithm does not solve all possible
       problems.  The digest values could be mistranscribed, or
       even though the counts are the same, the sets of underlying
       objects for some pair of algorithms might still not be

Larger question:

     * Is this the right agility protocol?  It seems to me to be
       roughly the best we can do given the structure of TLSA