On Tue, Mar 10, 2009 at 08:35:40AM +1100, Mark Andrews wrote:
>
> 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
if the child produces the DS, then the TTL is preserved.
if the parent produces the DS, then the TTL is not.
i'd think that would be a reason to use DS as the record to
publish.
--bill
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
