And as DNS is loosely coherent a validator cannot check this rule even when getting answers from a single IP address as there may be a anycast server behind that address. This loose coherence allows for servers to incrementally sign a zone when introducing a new algorithm. A incrementally signed zoned for a algorithm is no different to a incoherent zone for the purposes of validation.
You don’t publish DS records (or trust anchors) for a algorithm until the incoherent state is resolved (incremental signing with the new algorithm is complete). The same applies to CDS and CDNSKEY. You can only check if all records are signed with a given algorithm by performing a transfer of a zone and analysing that. There is no way to do it with individual queries. As for the original question, if all the DNSKEYs for a algorithm are revoked I would only be signing the DNSKEY RRset with that algorithm. The zone will appear to be in a incoherent state but that isn’t a issue unless there are still DS records referencing that algorithm which there shouldn’t be if they are all revoked. > On 13 Apr 2019, at 6:00 am, Edward Lewis <edward.le...@icann.org> wrote: > > I've been inactive a long time, but someone alerted me to this message. > (Apologies what below looks like it's from a ranting lunatic. But it is.) > > On 4/12/19, 11:31, "DNSOP on behalf of Mark Andrews" <dnsop-boun...@ietf.org > on behalf of ma...@isc.org> wrote: > > Well given that the actual rule is all the algorithms listed in the DS > RRset > rather than DNSKEY RRset and is designed to ensure that there is always a > signature present for each of the algorithms that could be used be used to > declare that the child zone is treated as secure, the answer is NO. > > Mark > > Looking at "Protocol Modifications for the DNS Security Extensions" (aka RFC > 4035): > ... > 2. Zone Signing > ... > 2.2. Including RRSIG RRs in a Zone > ... > There MUST be an RRSIG for each RRset using at least one DNSKEY of > each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset > itself MUST be signed by each algorithm appearing in the DS RRset > located at the delegating parent (if any). > > From this I believe Mark's words are incorrect. What I read is that the > determining factor is what is in a zone's DNSKEY resource record set and that > the set must be signed by a key of each of the algorithms in the DS set. > This allows the child administrator to have DNSKEY records for DNSSEC > security algorithms other than those represented in the parent's DS resource > record set and does accommodate other signatures covering the DNSKEY record > set. > > Historically there's been great confusion over this passage, partly because > the context is usually missed. This rule governs the actions of signing and > serving a zone, not validating a zone. The purpose of the rule is to allow a > validator to "know" deterministically what signatures ought to be present for > data. This is needed to mitigate a downgrade attack enacted by simply > filtering signature records. The validator need not check to make sure all > "required" signatures are available, it should be content with anything that > works. I.e., be aggressive in declaring success in the validation process to > combat the brittleness introduced by DNSSEC. (This is intentional, not an > afterthought.) > > Imagine one is descending the tree, and determines that the parent's zone > data is signed by DNSSEC. Taking the next step downward toward the desired > data, the DS resource record set indicates how the child is secured. Proven > absence of a DS resource record set means the parent considers the child is > unsigned (whether the child is or not). > > One ought to imagine that when these rules were written, it was assumed > validators taking these steps might not "know" all of the DNSSEC security > algorithms. I.e., a validator might know '8' but not '13'. If a parent used > '8' to sign, and the DS resource record set indicated that only '13' was used > by the child (the DS resource record set itself signed by '8'), then the > validator would treat the child as unsigned. But if there were an '8' in > there, then the child's DNSKEY set would have to be signed with '8' so the > chain would continue. > > It's possible that a child may have DNSKEY resource records for DNSSEC > security algorithms not supported by the parent operator. A child operator > may have arranged to have trust anchors in all relying validators out of band > to make this "still work." This is the reason the determination is from the > zone's apex DNSKEY resource record set and not the parent's DS resource > record set. > > Remember a child is "delegated" responsibility for a domain. The parent only > "gives it life". What a child zone says about itself rules, local policy and > all that. A child may be under a non-DNSSEC parent and still practice DNSSEC > with the validators it has out-of-band contact with. > >> On 13 Apr 2019, at 1:05 am, Michael StJohns <m...@nthpermutation.com> wrote: >> >> Hi - >> >> I had someone ask me (last night!!) whether or not the "must sign each RRSet >> with all of the algorithms in the DNSKEY RRSet" rule applies if the only key >> with algorithm A in the RRSet has the revoke bit set. A question I had >> never previously considered. >> >> Given that you can't trace trust through that revoked key, and any RRSig >> originated by that key is just extraneous bits, I came to three conclusions: >> 1) A key must not be counted for the purposes of the rule if it has the >> (RFC5011) revoke bit set, (s) the only RRSigs created by a revoked key are >> over the DNSKEY RRSet and 3) it's possible/probable that interpretations >> could differ. >> >> I tagged this email with the algorithm update ID/RFC candidate because about >> the only time you're going to see a revoked singleton key of a given >> algorithm is when you're transitioning the algorithms for the zone. >> >> I hesitate to ask - and apologize for asking given the late date for this >> document, but should the statements (1) and (2) above or something similar >> be included in this document for completeness? >> >> Alternatively, what breaks if publishers omit the extraneous signatures just >> because? >> >> Later, Mike >> >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=9G8-4P__AMgxNOQPiu7FkrImeieALKYtfGBE8UTuyg4&m=DtciL5VzyZx7OClOtqUTww43cMYicviMBswr8exaSDY&s=hhHQojjyYRP4yldSvlX44aLMDFadmag-M2RKi35PI48&e= > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=9G8-4P__AMgxNOQPiu7FkrImeieALKYtfGBE8UTuyg4&m=DtciL5VzyZx7OClOtqUTww43cMYicviMBswr8exaSDY&s=hhHQojjyYRP4yldSvlX44aLMDFadmag-M2RKi35PI48&e= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
