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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
