Hi I have some comments on the document draft-barwood-dnsop-ds-publish-01:
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. 1. Introduction (5th paragraph) The CDS RR would not be used for automation of rollovers but rather the automated key exchange from child to parent. (Key exchange is one step in the rollover process) 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. 3. Usage (1st paragraph) How do you know what name server to send the NOTIFY to? SOA MNAME? Configurable option? Service discovery? etc 3. Usage (2nd paragraph) I think you should change the SHOULD to a MUST: "The parent zone MUST attempt to authenticate" 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. 3. Usage (3rd paragraph) Nothing prevents you from having a DS RR pointing to a zone signing key. Thus no need to do this check. 3. Usage (7th paragraph) And since I am trying to remove the constraint on only using a KSK to create a signature for this RRset, you should also change: "where a key signing key has been compromised" to "where a key has been compromised" // Rickard _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
