On 1/6/2015 9:42 PM, Viktor Dukhovni wrote:
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.
Right...all the questions that I am intentionally avoiding in this
thread (see original post) <g>.
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.
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
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
