Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt

Viktor Dukhovni <viktor1dane@dukhovni.org> Thu, 06 February 2014 20:39 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE771A01E3 for <dane@ietfa.amsl.com>; Thu, 6 Feb 2014 12:39:33 -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 9caZ3gIpMv0R for <dane@ietfa.amsl.com>; Thu, 6 Feb 2014 12:39:31 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1541C1A03CA for <dane@ietf.org>; Thu, 6 Feb 2014 12:39:30 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C3A1D2AB23D; Thu, 6 Feb 2014 20:39:28 +0000 (UTC)
Date: Thu, 6 Feb 2014 20:39:28 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140206203928.GE278@mournblade.imrryr.org>
References: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com> <20140206195322.GD278@mournblade.imrryr.org> <62C57F51-CDB7-4784-9348-91D073103F4F@verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <62C57F51-CDB7-4784-9348-91D073103F4F@verisign.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt
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: Thu, 06 Feb 2014 20:39:33 -0000

On Thu, Feb 06, 2014 at 08:17:10PM +0000, Osterweil, Eric wrote:

> > Switching gears, was any consensus reached on the endoing of the
> > query label?  A truncated HMAC seems to offer better usability than
> > base32.  I think that the specification is in good shape, modulo
> > the query label encoding.  
> 
> I actually have a question on this: is there some reason we are
> talking about HMAC instead of just straight-up using a hashing
> function?  iirc, hashing accomplishes the same goal (for us) w/o
> needing any secret material (projecting a variable length name to
> a fixed length label).  I'm fully willing to believe that I might
> just be missing something.  I mean this just as a simple clarification
> question.

HMAC was proposed to *salt* the hash with a domain-specific key
(namely the domain itself).  The key is NOT secret, but it is
distinct for every domain (encoded in punycode for IDNA domains).

The reason for salting the lookup keys is to make dictionary attacks
on the set of email addresses more expensive.  One could even
NSEC3-style require some number of iterations, but this would
arguably be going too far and there is not a good way to signal to
the client what the iteration count should be.

Clearly any kind of one-way function is harder to brute-force invert
than the trivially reversible base32.  And salting makes rainbow-tables
less practical.  Still Bitcoin mining has led to rather fast hash
dictionary attack codes, and perhaps even salted HMAC is fast enough
to make DNS lookup a viable directory harvesting (via DNS lookup)
attack vehicle.

-- 
	Viktor.