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=
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
