Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-algorithm-update

[Edward Lewis <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> 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 <[e-mail]> 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
    > [e-mail]
    > 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: [phone]              INTERNET: [e-mail]
    
    _______________________________________________
    DNSOP mailing list
    [e-mail]
    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=