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. >> 3. Resource Record Format (3rd paragraph) >> I do not think you should limit what key type can be used for creating the >> signature for this RRset. As long as the parent can verify it using the >> previous DS RRset via the child's DNSKEY RRset. In fact, forcing the use of >> KSK for this RRset's signature will break some assumptions in the key timing >> draft. > > Can you be more explicit about how it conflicts with the key timing draft? > The logic for restricting the key type is that where a ZSK private key is > kept online, > a breach of security would not allow the parent DS to be disrupted ( and such > disruption > could be difficult to reverse ). This seems a solid advantage, and I don't > see any disadvantage. The definition is that the KSK creates signatures for DNSKEY RRset. This creates some assumptions for the various KSK mechanisms. Because you know that the signatures created with this key are bundled only with the DNSKEY RRset. You thus know when signatures are removed from caches etc. And that you know that a DNSKEY can be removed at once without postpublishing (or made active with no prepublishing), since there are no other RRset that needs to be validated with this key. DNSKEY RRset + RRSIG are always cached together. Yes, you are right. You are then relying on the security of the ZSK to update the DS. >> 3. Usage (1st paragraph) >> How do you know what name server to send the NOTIFY to? SOA MNAME? >> Configurable option? Service discovery? etc > > The draft says "a name server for the parent zone". Is that not clear? It > means any one of the servers defined by > the parent NS RRset. I don't see any need for a more complex mechanism, but > suggest a more complex > mechanism if you think that is an improvement. Yes, that part is clear. But then you (the TLD) have to forward the update request from the secondary back to the hidden master / database. And the secondaries can also be outsourced to other parties, separate from the one owning the authoritative data. You probably want to send the update somewhere close to the source of the authoritative data. >> 3. Usage (2nd paragraph) >> "If the authentication succeeds or yields Insecure, extra security checks >> are not normally necessary" >> This statement makes it possible to do a DoS on this zone. An attacker could >> send a DS to the parent in the name of the unsigned child. This means that >> this draft should only be used after that the first initial key exchange has >> been done, where the parent can actually use DNSSEC to verify the changes. >> > > I suggest it's up to the policy of the parent zone ( and policy is not best > dealt with here). > An insecure zone is clearly insecure until it is signed. This possibility > would encourage > owners of child zones to sign the zone, as once signed this vulnerability > disappears. > In practice most parent zones would probably require some manual step in > addition > ( using the same access as is currently used to maintain the NS RRset in the > parent ). > But the alternate policy has an incentive effect, so should be permitted I > think. No, I would not like to implement this. This would mean that an attacker could inject fake DS RR to all of our unsigned child zones. There is no authentication mechanisms if you have not done the first initial key exchange using channels like EPP, where you upload the first DS. This is a Denial of Service since the child zone then get marked as bogus. DS in the parent, but the child has no signatures. 1. Upload the first DS manually using EPP or similar. 2. Enable the mechanism in this draft. > Thanks for your comments. Would you support the adoption of this draft by the > WG? You're welcome. My comments now was just now on the design. I have to do some more thinking and compare this with other solutions. // Rickard _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
