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

From: Sean Leonard <[email-masked]>
Date: Tue, 06 Jan 2015 21:20:24 -0800

Hello:

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.

Looking back at the archives, it appears that a motivator for SHA-224 is 
that it is "short" and therefore fits in a DNS label with hex encoding. 
I do not buy this argument. Base32 encoding works great for SHA-256.

Since DNS labels are octets anyway, if you want "short" I do not see a 
big deal with putting 32 octets in the label. Pushback on the grounds 
that "it's not a hostname" and "watch out for case folding" are moot 
because "_smimecert" is not a valid hostname either: that's why "_" was 
chosen for SRV records and their kin. It's not a vanity contest. Maybe 
there are other considerations; I am not a DNS ops expert. Suffice to 
say, base32 would work just fine.

(As an implementer, I have other various opinions about this work but 
don't feel like bringing them up at this time.)

Sean

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 Jan 2015 05:42:16 +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.

---

From: Sean Leonard <[email-masked]>
Date: Tue, 06 Jan 2015 23:14:26 -0800

> of address extensions, ...), which are otherwise difficult.

Right...all the questions that I am intentionally avoiding in this 
thread (see original post) <g>.

> 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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 7 Jan 2015 13:45:46 -0500 (EST)

>> <http://msdn.microsoft.com/library/bb931357>. I suggest sticking with

Wish we had known that sooner :(

> it from truncated SHA2-256 output.

I have no problem with this for OPENPGPKEY.

> to authenticate a dedicated lookup service

Actually, this has nothing to do with the problem of the hash of the
username which is needed to _find_ the DNS record. You are talking about
adding another level of indirection for the return _data_ and you'll be
adding another choke/failure/filter point people can attack to prevent
you from publishing your key

Plus, a mechanism already exists to solve what you (not I) deem to be a
problem:

danm._pka.prime.gushi.org.  TXT         "v=pka1;fpr=C2063054549295F3349037FFFBBE5A30624BB249;uri=http://prime.gushi.org/danm.pubkey.txt"

Perhaps someone wants to run a fetch on the RIPE ATLAS network for:

ab16de0656382d91838914109ab89a0a4e04321550a1a20ace7a8b66._openpgpkey.nohats.ca

and see how many sites cannot get the data back?

>  Using something other than DNS would allow the

We've been waiting for 20 years. Pervasive monitoring etc...

ExecSum: If we use a truncated sha2_256 in smime, we should use it in openpgpkey
too. We should try to keep these two in sync. Not storing key data in
DNS is off-topic.

Paul