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

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 07 January 2015 05:42 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 780071A1A33 for <dane@ietfa.amsl.com>; Tue, 6 Jan 2015 21:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lPwhuQdYu5mK for <dane@ietfa.amsl.com>; Tue, 6 Jan 2015 21:42:18 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13E71A1A27 for <dane@ietf.org>; Tue, 6 Jan 2015 21:42:17 -0800 (PST)
Received: by mournblade.imrryr.org (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 <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20150107054216.GV7322@mournblade.imrryr.org>
References: <54ACC218.8070507@seantek.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54ACC218.8070507@seantek.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/urSjITfBoFhkOanKhzDlEWmtepE
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
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: 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:
> <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.

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.

-- 
	Viktor.