[dns-wg] DNSSEC deployment on the reverse tree.

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