In message <200903091515.n29ffetp055...@stora.ogud.com>, Olafur Gudmundsson wri
tes:
> --===============0733757033==
> Content-Type: multipart/alternative;
> boundary="=====================_777355448==.ALT"
>
> --=====================_777355448==.ALT
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> 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
On a related issue DS -> DNSKEY translations cannot be
performed until the DNSKEY is published in the zone. The
use of DS prevents pre-publishing of keys.
I can see no real reason to recommend that DS records be
published in preference to DNSKEY records.
DNSKEY -> DS is a conversion that can be at anytime.
This make DNSKEY a better manditory record to publish.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
