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
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane