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

[Paul Wouters <[e-mail]>]

On Wed, 7 Jan 2015, Viktor Dukhovni wrote:

> 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.

Wish we had known that sooner :(

> 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.

I have no problem with this for OPENPGPKEY.

> 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

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
> lookup service to handle key canonicalization (case folding, handling
> of address extensions, ...), which are otherwise difficult.

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