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

James Cloos <> Thu, 09 January 2014 19:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8587D1AE3D5 for <>; Thu, 9 Jan 2014 11:51:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ukmQR4EFIclb for <>; Thu, 9 Jan 2014 11:51:52 -0800 (PST)
Received: from ( [IPv6:2604:2880::b24d:a297]) by (Postfix) with ESMTP id 69FAF1AE114 for <>; Thu, 9 Jan 2014 11:51:52 -0800 (PST)
Received: by (Postfix, from userid 10) id 4FF891DEB5; Thu, 9 Jan 2014 19:51:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ore13; t=1389297099; bh=NsQM+qjiYS2Xb78QFeGOMcW5+4hFAFfXLhfYATPOZGs=; h=From:To:Subject:In-Reply-To:References:Date:From; b=H4w/I/csb7GXTQb53xrxUrPJVOHMf+eRmdqD2Bz5oqgKplWwI+eh/1p0g2/8xq1x/ dtXWHh2QFDtqRC5Cp9j9kLjKl/200wyyDC9wiClOTLqTjQ9EMJyZp9h8oLg/VlAXHx uQ8D67hd9cb28uM1ykfgcq0z1CzSgCr+rQZeYz2tISQ==
Received: by (Postfix, from userid 500) id 96FE360027; Thu, 9 Jan 2014 19:45:50 +0000 (UTC)
From: James Cloos <>
In-Reply-To: <> (Viktor Dukhovni's message of "Thu, 9 Jan 2014 17:39:43 +0000")
References: <> <> <>
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux)
Copyright: Copyright 2013 James Cloos
OpenPGP: ED7DAEA6; url=
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
Date: Thu, 09 Jan 2014 14:45:50 -0500
Message-ID: <>
Lines: 35
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
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: Thu, 09 Jan 2014 19:51:55 -0000

>>>>> "BD" == Brian Dickson <> writes:
>>>>> "VD" == Viktor Dukhovni <> writes:

BD>> So instead of "encoding" per se, what about using a hash function?
BD>> ... re-use of the NSEC3 code might be reasonable

VD> An intriguing suggestion.


VD> If the hash is HMAC-SHA1(domain, username), its hex representation
VD> is 40 octets which fits comfortably into a DNS label.

As hex; and 40 hex vs 32 base32 isn't enough of a difference to warrant
adding extra code for base32.  A win overall.

Should anyone insist of hmac-sha256, though, base32 would be necessary.
But I've yet to see any credible claims that sha1's vulnerabilities
affect hmac-sha1, so there shouldn't be a reason for sha2 or sha3.

VD> HMAC with the domain as a key makes rainbow tables less useful.

If hmac nonetheless isn't used, then the nsec3 hash SHOULD be.

The issue of normalization (before hashing) remains, as foo will
generate a different hash than LHS or Lhs (or lHs), not to mention
the differences between NFC vs NFD (eg, <U+E4> vs <U+61 U+308>).

I like the idea of a published policy (perhaps using the token _policy)
to specify the details for that zone.  With lc(nfc(lhs)) as the default
policy, if none is specified.

James Cloos <>         OpenPGP: 1024D/ED7DAEA6