-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
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.
When removing an old algorithm, the same problem can occur when the
signatures expire in the cache before the keyset.
This can be prevented by not adding or removing both the keys and the
signatures at the same time.
Proposed addition to rfc4641diff attached in the hopes that the text is
not mangled by my mail client. It might need a bit more of the problem
description though.
Any thoughts?
Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAki/r2YACgkQ4nZCKsdOncU9FACgoDkXP0PUjrdZTiJmiXNpxJ8X
oMEAoJBougDT51O6MacOpzoV8/5ZsUyg
=ab7S
-----END PGP SIGNATURE-----
When rolling 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.
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.
To do both, the following steps can be used. For simplicity, we use a
zone that is only signed by one zone signing key.
----------------------------------------------------------------
1 Initial 2 New RRSIGS 3 New DNSKEY
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG1(SOA0) RRSIG1(SOA1) RRSIG1(SOA2)
RRSIG2(SOA1) RRSIG2(SOA2)
DNSKEY1 DNSKEY1 DNSKEY1
RRSIG1(DNSKEY) RRSIG1(DNSKEY) DNSKEY2
RRSIG2(DNSKEY) RRSIG1(DNSKEY)
RRSIG2(DNSKEY)
----------------------------------------------------------------
4 Remove DNSKEY 5 Remove RRSIGS
----------------------------------------------------------------
SOA3 SOA4
RRSIG1(SOA3) RRSIG2(SOA4)
RRSIG2(SOA3)
DNSKEY2 DNSKEY2
RRSIG1(DNSKEY) RRSIG2(DNSKEY)
RRSIG2(DNSKEY)
----------------------------------------------------------------
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.
After the cache data has expired, the new key can be added to the zone,
as done in step 3.
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.
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
