Subject: [dnsext] algorithm rollover

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 04 Aug 2010 17:27:35 +0200

Hi,

Key algorithm rollover needs to be described better.

In 4641-bis, on introducing a new algorithm, removing an algorithm, and
removing an algorithm with Revoke.

In dnssecbis-updates, that revoked keys can sign not only the DNSKEY set
they are in, but are also allowed to sign the entire zone contents for
backwards compatibility with non-5011 validators when removing an
algorithm [or some other specific delineation what revoked keys can and
can not sign].  And text that RRSIGs MUST exist for a key that is not in
the DNSKEY rrset during such algorithm changes: a zone MAY contain
RRSIG's for an DNSKEY that does not exist in the DNSKEY RRset.

* introducing a new algorithm.
1) add signatures on entire zone with algorithm
2) publish ZSK for the algorithm
3) publish KSK for the algorithm
4) publish DS for the algorithm.
With TTL waits between steps.

* removing an algorithm
1) remove DS for the algorithm
2) remove KSK for the algorithm
3) remove ZSK for the algorithm
4) remove signatures on the entire zone for the algorithm
With TTL waits between steps.

* removing an algorithm with 5011-REVOKE for KSK.
1) remove DS for the algorithm
2) publish KSK with REVOKE flag.
3) remove KSK for the algorithm
4) remove ZSK for the algorithm
5) remove signatures on the entire zone for the algorithm
With TTL waits between steps.

Other options for removal of an algorithm are
* Go MISSING.
use the steps for removal without the REVOKE publish step.  The key goes
into 5011-MISSING state.  And is removed after a time (180 or 366 days
or so).  This may be an alternative for non ZSK-KSK split zones, since
they want things easy, and this is easy.

* Sign the entire zone with the removed KSK while it is REVOKED as well.
Some find this distasteful, but really, it is only a DNSKEY flag, just
like the SEP flag and carries meaning only to operators.  If you have a
ZSK/KSK split you do not have to do this.

Alternatively, for this a spec-change can be made that such 5011
revocations should be looked for by validators for any zone (not just
for trust-anchors), and revocations handled somehow.

Best regards,
   Wouter

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 05 Aug 2010 10:32:36 +0200

Hi,

> removing an algorithm with Revoke.

I have proposed text in the dnsop list.

> RRSIG's for an DNSKEY that does not exist in the DNSKEY RRset.

dnssecbis-updates does not talk about revoked keys, so there is no
restriction, so why should it go in there? I think it would be better to
make an errata or update on RFC 5011 in this case.

When it comes to algorithm rollover and RFC 5011, the backwards
compatibility can be solved by following the algorithm rollover
described in 4641bis + the earlier mentioned proposed text.

I would like to propose to change the text "a zone MAY contain RRSIG's
for an DNSKEY that does not exist in the DNSKEY RRset." with
"a zone MUST allow for RRSIG's for an DNSKEY that does not exist in the
DNSKEY RRset." It's a subtle change, but it enforcer implementations to
allow this, instead of giving them the choice to ignore/filter
signatures that don't match one of the keys in the DNSKEY set.

> With TTL waits between steps.

Yes, but such text is already in the 4641bis right and the proposed
text, right? Or do you prefer splitting it up in adding and removing
algorithms, instead of describing a rollover?

> they want things easy, and this is easy.

It is an option, though I argue if it is a good one. If you have a way
to properly rollover algorithms, why would you abuse the abnormal state
from 5011? It is true that it is more easy to implement than the proper
algorithm rollover.

> ZSK/KSK split you do not have to do this.

The issue with REVOKED bit is that you cannot know if it was revoked
because of a planned rollover, or if it was revoked because it is
compromised. That's why it may be distasteful.

Perhaps these two alternative options should also go into 4641bis.

> for trust-anchors), and revocations handled somehow.

This is too vague for me to understand what you mean...

Best regards,
Matthijs

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 05 Aug 2010 11:08:53 +0200

Hi Matthijs,

> signatures that don't match one of the keys in the DNSKEY set.

OK

> algorithms, instead of describing a rollover?

Since people want to do this, and removal of an algorithm hits corner
cases, this may be a good thing to do.

> from 5011? It is true that it is more easy to implement than the proper

Yes if you do the proper rollover that is nicer, with a ZSK of the
algorithm to sign the zone with.

> This is too vague for me to understand what you mean...

The REVOKE flag, what does it mean when the validator is not configured
for 5011 validation for a domain?  Does it change the validation
process?  Since 5011 does not say that it does, it does not change the
validation process at all, and is only a flag 'for indicating rollover'.
 Therefore a REVOKED key may be used by any zone, say as KSK.

Best regards,
   Wouter

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 05 Aug 2010 17:00:48 +0200

Hi Wouter,

> cases, this may be a good thing to do.

Ok, but that should go into 4641 then, and it is more suitable to
discuss that on the dnsop mailing list.

>  Therefore a REVOKED key may be used by any zone, say as KSK.

I interpreted 5011 in such a way that:
As a 5011-aware resolver, you should of course obey the REVOKED bit.
As a 5011-unaware resolver, you should ignore the bit, thus you can use
it for validation.

As a zone operator, I would not sign my complete zone with a key that I
publish as revoked. Better to sign the zone with the non-SEP key with
the same algorithm, those keys don't need to be revoked (as they will
not be picked up as trust anchors). Even with a single type key scheme
you need to introduce a non-SEP key, because otherwise you break
5011-aware resolvers (or let the old key go MISSING).

Best regards,
Matthijs