Subject: [DNSOP] draft-ietf-dnsop-algorithm-update

From: Michael StJohns <[email-masked]>
Date: Fri, 12 Apr 2019 11:05:37 -0400

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

---

From: Mark Andrews <[email-masked]>
Date: Sat, 13 Apr 2019 01:31:09 +1000

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

> On 13 Apr 2019, at 1:05 am, Michael StJohns <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Fri, 12 Apr 2019 20:00:50 +0000

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" <[email-masked] on behalf of [email-masked]> 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.

    > 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
    [email-masked]
    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=

---

From: Mark Andrews <[email-masked]>
Date: Mon, 15 Apr 2019 12:35:30 +1000

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 <[email-masked]> wrote:
>

---

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Apr 2019 13:21:44 +0000

A few follow ups:

On 4/14/19, 22:35, "DNSOP on behalf of Mark Andrews" <[email-masked] on behalf of [email-masked]> wrote:
    
>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).

While that makes sense, the protocol can't (not simply doesn't) forbid it.  The publisher of the DS resource record set may be a different entity than the publisher of the corresponding DNSKEY resource record set.  Because of the possibility of misalignment, the protocol as to be specific in order to be robust.
    
>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.

The historic error involved a resolver, upon receipt of a response, declaring a data set invalid when the set of RRSIG resource records did not cover all the DNSSEC security algorithms that the rules for zone signing specified, as opposed to validating the data set in question because there were sufficient records to build a secure chain.
    
>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.

This makes complete sense, but is not in-line with the letter of the protocol's rules.  That's the issue.

The consequence of following the protocol's current rules is a lot of deadweight.  Namely, unusable RRSIG resource records sent in each reply of authoritative data just to include the DNSSEC security algorithm.  The signatures need not make mathematic sense - as no one would need to validate them - with one exception. Where ever there is a division of key responsibilities such as having one organization manage the KSK and a different manage the ZSK, a ZSK may be "forced" to exist by rule and operational configuration.

(Removed the remainder of the thread history...)

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Apr 2019 00:03:37 +1000

Well I think it is time for more fine tuning.  It’s still only PS. 

-- 
Mark Andrews

> On 15 Apr 2019, at 23:21, Edward Lewis <[email-masked]> wrote:
> 
> A few follow ups:
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Apr 2019 14:17:39 +1000

> On 15 Apr 2019, at 11:21 pm, Edward Lewis <[email-masked]> wrote:
> 
> A few follow ups:
> 

They will normally be different entities.  The same is true for all delegations.  You can be robust and still have more nuanced rules.  Parents of a delegation should only be publishing DS records on the direction of the child.  We have a number of mechanism to pass that direction (inband: CDS, CDNSKEY,
out of band: EPP DS entries).

The intent of the rule was to prevent validation failures provided it was followed. i.e. if you follow this rule, validators should not produce a bogus result of validation provided you generate good signatures as they will have the necessary data.  Zones were the there isn’t a supported algorithm in the DS set are deemed to be insecure.  To prevent downgrade attacks you need to look at the DS set, not the DNSKEY set, as that should only be published before (removal of algorithm) / after (addition of algorithm) the natural incoherence resulting from updating zone content (DNSKEY RRset) has stabilised. 

That said downgrade attacks should be a non issue.  If a algorithm is too weak to validate a response it should be ignored, not conditionally used which is the only time one would care about downgrade attacks succeeding.

> The historic error involved a resolver, upon receipt of a response, declaring a data set invalid when the set of RRSIG resource records did not cover all the DNSSEC security algorithms that the rul…

Yep.

> This makes complete sense, but is not in-line with the letter of the protocol's rules.  That's the issue.

Basically the protocol rules in this area are and always have been too simple.  I should have pushed for more nuanced rules initially but I wasn't sure the working group was up to it.  They weren’t up to more nuanced rules to “always send CD=1” which should be struck from the RFC.

> (Removed the remainder of the thread history…)