Re: [dane] (draft-ietf-dane-smime) SHA-224 not in CryptoAPI

Viktor Dukhovni <> Wed, 07 January 2015 05:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 780071A1A33 for <>; Tue, 6 Jan 2015 21:42:20 -0800 (PST)
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 lPwhuQdYu5mK for <>; Tue, 6 Jan 2015 21:42:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F13E71A1A27 for <>; Tue, 6 Jan 2015 21:42:17 -0800 (PST)
Received: by (Postfix, from userid 1034) id 02D9E282CC6; Wed, 7 Jan 2015 05:42:16 +0000 (UTC)
Date: Wed, 7 Jan 2015 05:42:16 +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] (draft-ietf-dane-smime) SHA-224 not in CryptoAPI
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: Wed, 07 Jan 2015 05:42:20 -0000

On Tue, Jan 06, 2015 at 09:20:24PM -0800, Sean Leonard wrote:

> I would like to point out that SHA-224 is not a good choice for a fixed hash
> algorithm. SHA-224 is not implemented in Microsoft CryptoAPI / Cryptography
> Next Generation, which means that Windows apps (clients and servers) will
> have a more difficult time implementing this thing. Reference:
> <>. I suggest sticking with
> SHA-256.

A base32 encoding of SHA2-224 requires 45 octets, while SHA2-256
requires 52 octets.  Every little bit of space saved helps, DNS
names have a limited length.  One could of course truncate SHA2-256,
if availability of SHA2-224 is a major problem.  IIRC SHA2-224 is
essentially that, but is "salted" a bit differently to distinguish
it from truncated SHA2-256 output.

The larger question is whether putting per-user keys in DNS is the
right approach, or whether DNS should instead provide key material
to authenticate a dedicated lookup service that is not bound by
DNS encoding restrictions at all, which can in turn query alternative
sources (LDAP, ...)? Are user keys a good fit for DNS?  There was
some discussion of this a while back, but it just died down with
no conclusions.  Using something other than DNS would allow the
lookup service to handle key canonicalization (case folding, handling
of address extensions, ...), which are otherwise difficult.