At 13:46 06/08/2008, Paul Hoffman wrote:
Greetings again. The end of section 2 of this document says:
Another advantage of configuring a trust anchor using a DS record is
that the entire hash of the public key in the DS RDATA need not
necessarily be specified. A validating resolver MAY support
configuration using a truncated DS hash value as a human-factors
convenience: shorter strings are easier to type and less prone to
error when entered manually. Even with a truncated hash configured,
a validating resolver can still verify that the corresponding DNSKEY
is present in the trust anchor zone's apex DNSKEY RRSet. RFC 2104
[RFC2104] offers guidance on acceptable truncation lengths.
This is not correct. You cannot say "here is the SHA-256 hash of a
value" and then give less than 256 bits of the hash. If you wanted
to do this, you need to define the truncated hash and use that new
hash algorithm. So far, none of these truncated hashes have been
defined for DNSSEC, although ones could be defined.
Further, it is somewhat optimistic (and possibly sadistic) to think
that a user can type Base64 by hand for more than maybe ten
characters. This document should assume that the user is using
copy-and-paste, and therefore using the full 256 bits of the hash is
just as easy as using a truncated hash. If not, new, inherently
weaker, truncated hash algorithms need to be defined.
--Paul Hoffman, Director
--VPN Consortium
_
You are not the first person to bring this issue up, and upon reflection
we have dropped truncation discussion.
Olafur
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
