Richard and George, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Rickard Bellgrim > Sent: Thursday, November 11, 2010 8:32 PM > To: George Barwood > Cc: [email protected] > Subject: Re: [DNSOP] Comments on DS Publication draft > > > On 12 nov 2010, at 06.15, George Barwood wrote: > > >> 1. Introduction (3rd paragraph) > >> It is not always the case that the child is the one defining the DS > RRset. Some parents wants (for some reason) to create the DS RRset based > on their own policy (choice of hash) and based on what DNSKEY RR the child > send in. > > > > I'll take your word for this, but this practice seems a "very bad idea" > to me. > > I cannot see any justification, it just creates future inter-operability > barriers > > and obstacles for the introduction of new hash algorithms in future. > > It seems incompatible with the CDS concept ( or at least implies some > complication ). > > As the draft states, the ability to publish an arbitrary DS record in > the parent may be > > valuable in future, so it seems wise to retain that option. > > Yes, some TLD do this. The EPP protocol allows you to send the DNSKEY > instead of the DS RR. Other TLD:s also enforce you to have the DNSKEY > published before you can add the DS to the parent. But this is more a > discussion for RFC4641bis, where my own thought is that the TLD should > accept any (limited numbers of) DS from the child. > > But all of this does not make this draft useless. It is just that the zone > owner needs to know what the parent expect.
Or we could just publish a DNSKEY with another set of flags and leave it up to the parent to create the DS. That would be a nicer solution and we wouldn't have this problem. Additionally, I think the section justifying the new RR is weak. Especially, "delaying the time at which an attacker can start cryptanalysis". We are talking about hours or days here not decades, right? /S _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
