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

Sean Leonard <dev+ietf@seantek.com> Wed, 07 January 2015 07:15 UTC

Return-Path: <dev+ietf@seantek.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2C51A8966 for <dane@ietfa.amsl.com>; Tue, 6 Jan 2015 23:15:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83NsyfxPs_wB for <dane@ietfa.amsl.com>; Tue, 6 Jan 2015 23:15:36 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899C81A8960 for <dane@ietf.org>; Tue, 6 Jan 2015 23:15:36 -0800 (PST)
Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6326722E269 for <dane@ietf.org>; Wed, 7 Jan 2015 02:15:35 -0500 (EST)
Message-ID: <54ACDCD2.9070008@seantek.com>
Date: Tue, 06 Jan 2015 23:14:26 -0800
From: Sean Leonard <dev+ietf@seantek.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: dane@ietf.org
References: <54ACC218.8070507@seantek.com> <20150107054216.GV7322@mournblade.imrryr.org>
In-Reply-To: <20150107054216.GV7322@mournblade.imrryr.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CVJrkiECa0PgbR8pzng5rddKSm0
Subject: Re: [dane] (draft-ietf-dane-smime) SHA-224 not in CryptoAPI
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: 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:
>> <http://msdn.microsoft.com/library/bb931357>. 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.

Sean