Hello Sam, Thanks for the quick review.
(...) Many things in this look good (not rejecting keys without the SEP bit set, dealing with unsupported message digests, allowing multiple DS records), but I have a few concerns.
First, do you need to specify the encoding of the ds-rdata attribute in more detail?
This text is in the "Procedure for Requesting DNSSEC Delegations" The "ds-rdata:" attribute contains the RDATA of the DS Resource Records related to the domain (as shown in the "domain:" attribute). ds-rdata: 64431 5 1 278BF194C29A812B33935BB2517E17D1486210FA Is it ambiguous?
I'm worried about the first two rules in the "Delegation Checks" portion of this procedure. Assuming a working delegation chain is in place for each algorithm present in the DS set, it is really necessary to have each of the DNSKEYs present in the zone (the first rule)? I suggest instead: -- For each algorithm present in the set of ds-rdata attributes, is there a matching DNSKEY available in the DNS for at least one of the ds-rdata attributes with that algorithm? (Apologies for the poor word-smithing.)
The reason for this somewhat strong requirement is to prevent "DS lameness", just like you do not want delegation NS records pointing off to no-no-land you do not want to have DS records point to DNSKEYS that do not exist in the DNS. Although I could not quickly find a strong MUST for this requirement in RFC 4033-4035 I think it is good operational practice and will prevent many possible troubleshooting hours. (explaining the jargon: "security lameness" is a term from draft-ietf-dnsop-dnssec-operational-practices-04).
Also, the second test (valid RRSIG, presumably on the DNSKEY RRset) is only possible for supported crypto algorithms. Private algorithms may confound this rule. I suggest: -- "For each of the supported algorithms (3 and 5) present in the set of ds-rdata attributes, is there a valid RRSIG on the DNSKEY RRset made with a DNSKEY that both matches the ds-rdata attribute and is published in the DNS?" or -- "For each of the DNSKEYs identified by rule #1, is there at least one valid RRSIG on the DNSKEY RRset made with a DNSKEY of each algorithm?" And in the text below, say "Tests #2 and #4 will only be performed for supported algorithms". (Again, I suggest 3 and 5).
After we fixed these text a week or so ago we have been working on the more detailed specifications of the checks. We follow your above suggestion. That is, we provide a warning if we cannot validate the signatures because of the algorithm not being implemented (1,3 and 5). We provide information if the algorithm is not implemented. But we do plan to enforce a valid DS->DNSKEY->RRSIG(DNSKEY) chain. I think that a broken DS->DNSKEY->RRSIG(DNSKEY) chain is a recipee for operational trouble and is in 99.9% unintended. If operators really want to enter this dark spots in the corner case universe we can accommodate them and if it turns out that operators make this common practice than we can always relax the test. I should note that these delegations checks intended to prevent misconfigurations that can lead to hours of troubleshooting at the "client" end. The tests designed for DNSSEC are I think reasonable armour against shooting oneself in the foot. (When misconfiguring DNS you used to hurt your toe, when making mistakes with DNSSEC its amputation time).
Lastly, I don't understand this description of the web interface: "It will use the "ds-rdata:" attribute of the domain object currently available in the RIPE Whois Database to select the appropriate default DNSKEY RR. It will then select a new "ds-rdata:" attribute." Does this mean that the current ds-rdata will always be replaced?
The idea that the web-interface provides an aid to construct the Domain object. It takes sensible defaults. If somebody proceeds in a roll over the assumption is that the DS currently at the parent is replaced by a new one. You look at the keys in the zone with the SEP bit set. In the common case there will be two of those during a roll over, you pick the one not currently published by the parent as the new one. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC