Re: [dane] Feature creep for draft-ietf-dane-smime

Viktor Dukhovni <> Fri, 07 February 2014 02:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7AAE11A058F for <>; Thu, 6 Feb 2014 18:02:05 -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 o-TLaTUw_9UM for <>; Thu, 6 Feb 2014 18:02:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7F2091A0587 for <>; Thu, 6 Feb 2014 18:02:03 -0800 (PST)
Received: by (Postfix, from userid 1034) id DD7012AB23D; Fri, 7 Feb 2014 02:02:01 +0000 (UTC)
Date: Fri, 7 Feb 2014 02:02:01 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <07a801cf23a1$a5b62c00$f1228400$> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Feature creep for draft-ietf-dane-smime
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: Fri, 07 Feb 2014 02:02:05 -0000

On Thu, Feb 06, 2014 at 05:26:55PM -0800, Paul Hoffman wrote:

> Why are we trying to make the names any more difficult to walk
> through than they would be for SMTP? The use of the hash was *purely*
> to allow longer LHSs, not to prevent enumeration. Enumeration has
> never been considered a serious problem for SMTP, and we should
> not be complicating our protocol to prevent it. Hash-of-LHS is
> simple and not prone to any misunderstanding.

SMTP does not yield an efficient offline attack.  There exist
popular milters that attempt to thwart "directory harvesting

Once there's a hash, it should at least (at no extra cost) include
the domain, to make the attack require per-domain computations.

However, what I forgot to take into account is that with DNSSEC
what the attacker learns are the NSEC3 hashes of the email address
query domain, so a single dictionary is already not an option
because the NSEC3 RRs need to be cracked and these are already
salted with the domain and additional salt value.

So the offline attack is already a per-domain attack even without
salting of the hashed label.  Thus perhaps including the domain is
not essential (but no reason not to).  What could offer much better
protection is O(100,000) iterations (i.e., O(0.1) CPU second to
compute a lookup key).  An interactive user may not notice, but a
legititmate bulk email engine sending encrypted mail may run into
noticeable latency.

I am not strongly advocating for this, more thinking out loud, in
case the issue resonates with the group.