On Tue, 5 Jul 2005 15:28:50 -1000 Randy Bush <randy@psg.com> wrote:

hi olaf,

for us simple-minded folk who do not track dnssec details, could you tell us what trusted key(s) we will have to load to securely verify the signed zones? and is there an idiot's howto?

Hello Randy, [Moved the discussion to dns-wg only, apologies for not setting the reply-to header] In the absence of a signed parent domain the trusted-keys will be made available through a secured web page. The keys will only be made available after we start signing the zone in production. Also see the last part of: http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html For a howto on to configure a validating server see: http://www.ripe.net/projects/disi/dnssec_howto/ or: http://www.ripe.net/projects/disi/dnssec_howto/dnssec_howto.pdf I hope this answers your question. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC

On Wed, 6 Jul 2005 05:17:28 -1000 Randy Bush <randy@psg.com> wrote:

...

In the absence of a signed parent domain the trusted-keys will be made available through a secured web page. The keys will only be made available after we start signing the zone in production.

Also see the last part of: http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html

sigh. and the rirs can not get together and do a ksk system for in-addr.arpa?

Randy, Positive experiences gained during the rollout by the RIPE NCC will no-doubt be of influence on the timeframe on which we'll see DNSSEC deployed on the in-addr.arpa domain. --Olaf (quickly turning into a politician :-) )

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