Subject: [DNSOP] rfc4641bis algorithm rollover corner cases

From: Alexander Gall <[email-masked]>
Date: Wed, 27 Jul 2011 17:19:20 +0200

I'm about to implement algorithm rollover according to section 4.1.5
of rfc4641bis into our homegrown DNSSEC key management system. In the
step named "new RRSIGs", the zone is supposed to include the signature
of DNSKEY_K_2 over the DNSKEY RRset containing DNSKEY_Z_1 and
DNSKEY_K_1.  The explanation for this is given as

  new RRSIGs:  The signatures made with the new key over all records in
      the zone are added, but the key itself is not.  This includes the
      signature for the DNSKEY RRset.  While in theory, the signatures
      of the keyset should always be synchronized with the keyset
      itself, it can be possible that RRSIGS are requested separately,
      so it is prudent to also sign the DNSKEY set with the new
      signature.

[Editorial: the last sentence should read "...to also sign the DNSKEY
set with the new key"]

I don't understand which corner case this is supposed to cover. The
relevant section of RFC4035 quoted in the draft says

    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).

My understanding of this is that there is no requirement for the
existence of the signature over the DNSKEY RRset by K_2 until the end
of the step "new DNSKEY", because up to that point, the DS doesn't
refer to algorithm 2 yet.

The same reasoning appears to me to apply to the step "DNSKEY
removal".  At that point, the DS record refers only to algorithm 2 and
the old DS record has expired. Therefore, RRSIG_K_1(DNSKEY) should not
be needed either.

What am I missing?

-- 
Alex

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 27 Jul 2011 18:03:30 +0200 (CEST)

Hi Alexander,

>> [Editorial: the last sentence should read "...to also sign the DNSKEY

Thanks.

>> refer to algorithm 2 yet.

My understanding of this paragraph is that there MUST be an RRSIG for
each RRset using at least one key of each algorithm in the DNSKEY RRset.
So that includes the DNSKEY RRset itself. *In addition*, the DNSKEY RRset 
MUST be signed with the algorithms appearing in the DS RRset.

The corner case tries to make clear that a DNSKEY RRset can be
treated as part of the chain of trust, but also can be treated as zone
content. In the latter case you want to make sure that the signatures
of the new algorithm are propagated before introducing the new DNSKEY.

Best regards,

Matthijs

>> _______________________________________________
>> DNSOP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>

---

From: Alexander Gall <[email-masked]>
Date: Wed, 27 Jul 2011 20:58:23 +0200

Matthjis,

> MUST be signed with the algorithms appearing in the DS RRset.

Ok, so the snippet from 4035 alone appears to be ambigous to me.  Is
this clarified somewhere?

> of the new algorithm are propagated before introducing the new DNSKEY.

I sort of understand the intention.  But how *exactly* would it work?
Note that the "pre-published" signature in zone SOA_1 will differ from
that in zone SOA_2, because the DNSKEY RRset is not the same (this is
different from pre-published signatures by the ZSK, because the RRsets
themselves do not change). Suppose a validator happens to fetch the
DNSKEY RRset from SOA_2 but still has RRSIG_K_2(DNSKEY) from SOA_1 in
its cache.  I guess this is one of the corner cases, right? However,
wouldn't the validator be unable to verify that RRSIG because it
covers a different DNSKEY RRset (the one without Z_2 and K_2)?

It seems like to cover this case, you'd have to pre-publish the
signature of the DNSKEY RRset that will appear in SOA_2.  It's not
obvious to me whether this doesn't create problems of its own.

-- 
Alex

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 28 Jul 2011 19:29:31 +0200 (CEST)

> this clarified somewhere?

Perhaps draft-ietf-dnsext-dnssec-bis-updates can add that clarification, 
if appropriate.

> themselves do not change).

It's about pre-publishing the algorithm. But I now see what you mean and 
I think you are right. The corner case does not actually need these 
special considerations. The algorithm rollover described as it is now is 
not wrong, it just adds a redundant signature in the 'new RRSIGs' step.

Thanks for the catch.

> Suppose a validator happens to fetch the
> its cache.

Can this even happen? It is my understanding that if you have to fetch a 
new copy of the DNSKEY RRset, you automatically would get the 
corresponding signatures.

> I guess this is one of the corner cases, right? However,

If a validator would be able to get in this situation, yes. But I don't 
think this is possible.

> obvious to me whether this doesn't create problems of its own.

That sounds very complex to me too.

I think in order to fix the document, the text about the corner case 
should be removed, as well as the redundant signature in the rollover 
figure.

Best regards,

Matthijs

---

From: Alexander Gall <[email-masked]>
Date: Fri, 29 Jul 2011 09:24:04 +0200

On Thu, 28 Jul 2011 19:29:31 +0200 (CEST), Matthijs Mekking <[email-masked]> said:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> not wrong, it just adds a redundant signature in the 'new RRSIGs' step.

Ok. In other words, there is no point in publishing signatures over
the DNSKEY RRset by a key that is not part of that RRset itself,
right? Seems to me that RRSIG_K_1(DNSKEY) should be removed from the
"DNSKEY removal" step as well.

-- 
Alex

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 29 Jul 2011 17:14:44 +0200 (CEST)

> "DNSKEY removal" step as well.

Yes, I have proposed pending changes here:

http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-dnsop-rfc4641bis-07.txt&url2=http://www.nlnetlabs.nl/~matje/draft-ietf-dnsop-rfc4641bis.txt