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