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

Sean Leonard <> Wed, 07 January 2015 07:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1B2C51A8966 for <>; Tue, 6 Jan 2015 23:15:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 83NsyfxPs_wB for <>; Tue, 6 Jan 2015 23:15:36 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 899C81A8960 for <>; Tue, 6 Jan 2015 23:15:36 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6326722E269 for <>; Wed, 7 Jan 2015 02:15:35 -0500 (EST)
Message-ID: <>
Date: Tue, 06 Jan 2015 23:14:26 -0800
From: Sean Leonard <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
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 07:15:39 -0000

On 1/6/2015 9:42 PM, Viktor Dukhovni wrote:
> 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.

Right...all the questions that I am intentionally avoiding in this 
thread (see original post) <g>.

> 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.

If we are quibbling about 7 octets, I think we really have lost 
perspective on this.

For 99.99999999% of all e-mail addresses, just encoding the local-part 
as-is in a single DNS label would be the shortest. That is the approach 
somewhat-but-not-quite taken by CERT RRs [RFC4398].

Various justifications of hashing have been given on this list. Some 
advocate for HMAC-ing with some per-domain key. There is a lot of 
literature on the attacks thwarted and attacks let through with these 
approaches. Mostly, I don't think applying any transform buys you 
meaningful security; it just lets you map long local-parts to a single 
DNS label.

The difference between 32, 45, and 52 octets is negligible. In all 
seriousness: the domain-part is not going to be greater than 201 
octets/characters for an e-mail address, even with IDNA. The RR payload 
is going to be significantly larger than the name anyway.