Subject: [DNSOP] Truncation discussion in draft-ietf-dnsop-dnssec-trust-anchor-02

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Aug 2008 10:46:13 -0700

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
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop