Olaf,
here you have diff (against up-to-date SVN) and full text for Key
Algorithm Rollover. The attached text was created as joint effort by me
and Olafur.
Ondrej.
On 20.3.2010 17:10, Olaf Kolkman wrote:
Colleagues
This is a status update on RFC4641bis. Please refer to links provided for more
details on the issues. I have no particular issues I need to discuss in the
face to face meeting and will present what is written below in a somewhat
condensed form. If folk have something they would like to discuss it is
probably best to give a heads-up here.
High level summary:
Most changes in the document are with respect to the description about keys and
key maintenance (section 3). I've tried to stress the operational tradeoffs and
make those the basis of the cryptographic considerations. The idea is that the
tradeoff between costs and threats set the operational handling of the keys.
Once you know how you want to handle the keys operationally set the appropriate
crypto parameters.
Also there is a completely new section on the Next Record types (section 5) and
there are considerations added about the changing ones dns operator (section
4.4.5)
In detail
- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/HSMs
Addressed in a section 3.1.4.3 "Private Key Storage"
I believe this issue to be resolved.
- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/NSEC-NSEC3
Complete new section 5.
There is one remaining point there brought up in
From: Florian Weimer<fwei...@bfk.de>
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
Date: February 22, 2010 11:20:16 PM PST
To: Olaf Kolkman<o...@nlnetlabs.nl>
Cc: Alex Bligh<a...@alex.org.uk>, Paul Wouters<p...@xelerance.com>, dnsop
WG<dnsop@ietf.org>
NSEC making the packet too big base on the argument that " However, NSEC
records are sometimes returned in response to
DO=0 queries"
I believe there is consensus that that is caused by an implementation bug.
Therefore the issue can be closed.
- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Review-NIST
Scott reported that this issue can be closed.
- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency
- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/cryptography_flawed
-
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/discussion_of_timescales
- http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/rollover_assumptions
I believe these issues where addressed by reordering and rewriting parts of
section 3. But this section may need a little more work to clarify that the
approach is from operational perspective rather than a highest achievable
crypto perspective.
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/non-cooperative-registrars
Added as:
4.4.5.2. Non Cooperationg DNS Operators
This issue is resolved although a review of the supporting figure is needed.
The following issues have not yet been addressed and the issue needs to be
reviewed on relevance against the current version
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_and_parent_keys
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/trust_anchor_configuration
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/timing_terminology
I've added
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Signature_validity
From the recent mail from Sebastian where he asks for guidance on signature
validity intervals
that is an issue that is probably closely related to
http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/timing_terminology
which I will address in the next version.
--
Ondřej Surý
vedoucí výzkumu/Head of R&D department
-------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Americka 23, 120 00 Praha 2, Czech Republic
mailto:ondrej.s...@nic.cz http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------
$Id: Key_algorithm_roll 38 2010-02-17 14:12:44Z olaf $
2008090400
Key algorithm rollover section
Jelte Jansen
Added: 5 Sept 2008
http://www.ietf.org/mail-archive/web/dnsop/current/msg06707.html
During some work on DNSKEY maintenance, I think i found a potential
operational issue. If we are going to do new work on DNSSEC Operational
Practices, I would like to suggest to add a text similar to that
attached to this message.
The issue lies in the combination of algorithm downgrade protection and
caching, and can result in a small window of time (depending on TTLs),
where all data in a zone could be considered bogus by validators.
RFC4035 states the following (section 2.2):
There MUST be an RRSIG for each RRset using at least one DNSKEY of
each algorithm in the zone apex DNSKEY RRset.
While this poses no problem when an admistrator rolls a key with an
algorithm that is already present in the keyset, it can do so when
introducing new or removing old algorithms.
Caches may have both the old keyset and the old rrsets with signatures
stored. When a new keyset is introduced, and the keyset happens to
expire in the cache before the signatures do, the cache will retrieve
the new keyset. Since it still has the rrsets with old signatures, it
will see no reason to update those.
Now the validator will encounter a key with an algorithm for which
there are no signatures. This is prohibited by the earlier statement
in RFC4035, resulting in rejection of the data.
[Jelte Suggests text with tables]
Resolution:
Section 4.2.5 was introduced version 01.
4.2.4. Key algorithm rollover
[OK: The txt of this section is a strawman for the issue in: http://
www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll
]
A special class of keyrollover is the rollover of key algorithms
(either adding a new algorithm, removing an old algorithm, or both),
additional steps are needed to retain integrity during the rollover.
Because of the algorithm downgrade protection in RFC4035 section 2.2,
you may not have a key of an algorithm for which you do not have
signatures, and you may not have a DS record in the parent zone of an
algorithm for which you don't have a corresponding key in the zone
apex.
When adding a new algorithm, the signatures should be added first.
After the TTL of RRSIGS has expired, and caches have dropped the
old data covered by those signatures, the DNSKEY with the new
algorithm can be added.
After the new algorithm has been added, the DS record can be
exchanged using Double Signature Key Rollover. You cannot use
Pre-publish key rollover method when you do key algorithm rollover.
When removing an old algorithm, the DNSKEY should be removed first,
but only after the DS for the old algorithm was removed from the
parent zone.
To do both, the following steps can be used. For clarity, we use one
key signing key and one zone signing key for each algorithm. In
following table, we assume that DNSKEY_KSK_1 and DNSKEY_ZSK_1 are
DNSKEYS with the old algorithm and DNSKEY_KSK_2 and DNSKEY_ZSK_2 are
DNSKEYS with the new algorithm.
----------------------------------------------------------------
1 Initial 2 New RRSIGS 3 New DNSKEY
----------------------------------------------------------------
Child:
SOA0 SOA1 SOA2
RRSIG_ZSK_1(SOA0) RRSIG_ZSK_1(SOA1) RRSIG_ZSK_1(SOA2)
RRSIG_ZSK_2(SOA1) RRSIG_ZSK_2(SOA2)
DNSKEY_KSK_1 DNSKEY_KSK_1 DNSKEY_KSK_1
DNSKEY_ZSK_1 DNSKEY_ZSK_1 DNSKEY_ZSK_1
RRSIG_KSK_1(DNSKEY) RRSIG_KSK_1(DNSKEY) DNSKEY_KSK_2
RRSIG_KSK_2(DNSKEY) DNSKEY_ZSK_2
RRSIG_KSK_1(DNSKEY)
RRSIG_KSK_2(DNSKEY)
RRSIG_ZSK_1(*) RRSIG_ZSK_1(*) RRSIG_ZSK_1(*)
RRSIG_ZSK_2(*) RRSIG_ZSK_2(*)
Parent:
SOA0 SOA0 SOA0
RRSIGpar(SOA0) RRSIGpar(SOA0) RRSIGpar(SOA0)
DS_KSK_1 DS_KSK_1 DS_KSK_1
RRSIGpar(DS_KSK_1) RRSIGpar(DS_KSK_1) RRSIGpar(DS_KSK_1)
----------------------------------------------------------------
4 Exchange DS 5 Remove DNSKEY 6 Remove RRSIGS
----------------------------------------------------------------
SOA2 SOA3 SOA4
RRSIG_ZSK_1(SOA3) RRSIG_ZSK_1(SOA3) RRSIG_ZSK_2(SOA4)
RRSIG_ZSK_2(SOA3) RRSIG_ZSK_2(SOA3)
DNSKEY_KSK_1 DNSKEY_KSK_2 DNSKEY_KSK_2
DNSKEY_ZSK_1 DNSKEY_ZSK_2 DNSKEY_ZSK_2
DNSKEY_KSK_2 RRSIG_KSK_1(DNSKEY) RRSIG_KSK_2(DNSKEY)
DNSKEY_ZSK_2 RRSIG_KSK_2(DNSKEY)
RRSIG_KSK_1(DNSKEY)
RRSIG_KSK_2(DNSKEY)
RRSIG_ZSK_1(*) RRSIG_ZSK_1(*) RRSIG_ZSK_2(*)
RRSIG_ZSK_2(*) RRSIG_ZSK_2(*)
Parent:
SOA1 SOA1 SOA1
RRSIGpar(SOA1) RRSIGpar(SOA1) RRSIGpar(SOA1)
DS_KSK_2 DS_KSK_2 DS_KSK_2
RRSIGpar(DS_KSK_2) RRSIGpar(DS_KSK_2) RRSIGpar(DS_KSK_2)
----------------------------------------------------------------
Stages of Deployment during an Algorithm Rollover.
Step 1 describes state of the zone before any transition is done.
Number of the keys may vary, but the algorithm of keys in the zone is
same for all DNSKEY records.
In step 2, the signatures for the new key for 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 might be prudent
to also sign the DNSKEY set with the new signature.
After the cached data for all RRSIGS in the zone has expired, the new
key can be added to the zone, as done in step 3.
After the cache data for the DNSKEY has expired, the DS record for
the new key can be added to the parent zone and the DS record for the
old key can be removed in the same step.
After the cache data for the DS has expired, the old algorithm can
be removed. This time the key needs to be removed first, before
removing the signatures. The key is removed in step 5, and after
the cache data for the DNSKEY has expired, the signatures can be
removed in step 5.
The above steps ensure that during the rollover to a new algorithm,
the integrity of the zone is never broken.
Index: Key_algorithm_roll
===================================================================
--- Key_algorithm_roll (revision 63)
+++ Key_algorithm_roll (working copy)
@@ -55,55 +55,104 @@
Because of the algorithm downgrade protection in RFC4035 section 2.2,
you may not have a key of an algorithm for which you do not have
- signatures.
+ signatures, and you may not have a DS record in the parent zone of an
+ algorithm for which you don't have a corresponding key in the zone
+ apex.
When adding a new algorithm, the signatures should be added first.
- After the TTL has expired, and caches have dropped the old data
- covered by those signatures, the DNSKEY with the new algorithm can be
- added. When removing an old algorithm, the DNSKEY should be removed
- first.
+ After the TTL of RRSIGS has expired, and caches have dropped the
+ old data covered by those signatures, the DNSKEY with the new
+ algorithm can be added.
- To do both, the following steps can be used. For simplicity, we use
- a zone that is only signed by one zone signing key.
+ After the new algorithm has been added, the DS record can be
+ exchanged using Double Signature Key Rollover. You cannot use
+ Pre-publish key rollover method when you do key algorithm rollover.
+ When removing an old algorithm, the DNSKEY should be removed first,
+ but only after the DS for the old algorithm was removed from the
+ parent zone.
+
+ To do both, the following steps can be used. For clarity, we use one
+ key signing key and one zone signing key for each algorithm. In
+ following table, we assume that DNSKEY_KSK_1 and DNSKEY_ZSK_1 are
+ DNSKEYS with the old algorithm and DNSKEY_KSK_2 and DNSKEY_ZSK_2 are
+ DNSKEYS with the new algorithm.
+
----------------------------------------------------------------
- 1 Initial 2 New RRSIGS 3 New DNSKEY
+ 1 Initial 2 New RRSIGS 3 New DNSKEY
----------------------------------------------------------------
- SOA0 SOA1 SOA2
- RRSIG1(SOA0) RRSIG1(SOA1) RRSIG1(SOA2)
- RRSIG2(SOA1) RRSIG2(SOA2)
+ Child:
+ SOA0 SOA1 SOA2
+ RRSIG_ZSK_1(SOA0) RRSIG_ZSK_1(SOA1) RRSIG_ZSK_1(SOA2)
+ RRSIG_ZSK_2(SOA1) RRSIG_ZSK_2(SOA2)
- DNSKEY1 DNSKEY1 DNSKEY1
- RRSIG1(DNSKEY) RRSIG1(DNSKEY) DNSKEY2
- RRSIG2(DNSKEY) RRSIG1(DNSKEY)
- RRSIG2(DNSKEY)
+ DNSKEY_KSK_1 DNSKEY_KSK_1 DNSKEY_KSK_1
+ DNSKEY_ZSK_1 DNSKEY_ZSK_1 DNSKEY_ZSK_1
+ RRSIG_KSK_1(DNSKEY) RRSIG_KSK_1(DNSKEY) DNSKEY_KSK_2
+ RRSIG_KSK_2(DNSKEY) DNSKEY_ZSK_2
+ RRSIG_KSK_1(DNSKEY)
+ RRSIG_KSK_2(DNSKEY)
+
+ RRSIG_ZSK_1(*) RRSIG_ZSK_1(*) RRSIG_ZSK_1(*)
+ RRSIG_ZSK_2(*) RRSIG_ZSK_2(*)
+
+
+ Parent:
+ SOA0 SOA0 SOA0
+ RRSIGpar(SOA0) RRSIGpar(SOA0) RRSIGpar(SOA0)
+ DS_KSK_1 DS_KSK_1 DS_KSK_1
+ RRSIGpar(DS_KSK_1) RRSIGpar(DS_KSK_1) RRSIGpar(DS_KSK_1)
+
----------------------------------------------------------------
- 4 Remove DNSKEY 5 Remove RRSIGS
+ 4 Exchange DS 5 Remove DNSKEY 6 Remove RRSIGS
----------------------------------------------------------------
- SOA3 SOA4
- RRSIG1(SOA3) RRSIG2(SOA4)
- RRSIG2(SOA3)
+ SOA2 SOA3 SOA4
+ RRSIG_ZSK_1(SOA3) RRSIG_ZSK_1(SOA3) RRSIG_ZSK_2(SOA4)
+ RRSIG_ZSK_2(SOA3) RRSIG_ZSK_2(SOA3)
- DNSKEY2 DNSKEY2
- RRSIG1(DNSKEY) RRSIG2(DNSKEY)
- RRSIG2(DNSKEY)
+ DNSKEY_KSK_1 DNSKEY_KSK_2 DNSKEY_KSK_2
+ DNSKEY_ZSK_1 DNSKEY_ZSK_2 DNSKEY_ZSK_2
+ DNSKEY_KSK_2 RRSIG_KSK_1(DNSKEY) RRSIG_KSK_2(DNSKEY)
+ DNSKEY_ZSK_2 RRSIG_KSK_2(DNSKEY)
+ RRSIG_KSK_1(DNSKEY)
+ RRSIG_KSK_2(DNSKEY)
+
+ RRSIG_ZSK_1(*) RRSIG_ZSK_1(*) RRSIG_ZSK_2(*)
+ RRSIG_ZSK_2(*) RRSIG_ZSK_2(*)
+
+ Parent:
+ SOA1 SOA1 SOA1
+ RRSIGpar(SOA1) RRSIGpar(SOA1) RRSIGpar(SOA1)
+ DS_KSK_2 DS_KSK_2 DS_KSK_2
+ RRSIGpar(DS_KSK_2) RRSIGpar(DS_KSK_2) RRSIGpar(DS_KSK_2)
+
----------------------------------------------------------------
Stages of Deployment during an Algorithm Rollover.
- In step 2, the signatures for the new key are added, but the key
- itself is not. 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 might be prudent to also
- sign the DNSKEY set with the new signature.
+ Step 1 describes state of the zone before any transition is done.
+ Number of the keys may vary, but the algorithm of keys in the zone is
+ same for all DNSKEY records.
- After the cache data has expired, the new key can be added to the
- zone, as done in step 3.
+ In step 2, the signatures for the new key for 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 might be prudent
+ to also sign the DNSKEY set with the new signature.
- The next step is to remove the old algorithm. This time the key
- needs to be removed first, before removing the signatures. The key
- is removed in step 4, and after the cache data has expired, the
- signatures can be removed in step 5.
+ After the cached data for all RRSIGS in the zone has expired, the new
+ key can be added to the zone, as done in step 3.
+ After the cache data for the DNSKEY has expired, the DS record for
+ the new key can be added to the parent zone and the DS record for the
+ old key can be removed in the same step.
+
+ After the cache data for the DS has expired, the old algorithm can
+ be removed. This time the key needs to be removed first, before
+ removing the signatures. The key is removed in step 5, and after
+ the cache data for the DNSKEY has expired, the signatures can be
+ removed in step 5.
+
The above steps ensure that during the rollover to a new algorithm,
the integrity of the zone is never broken.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
