Subject: [DNSOP] suggestion for 4641bis: key algorithm rollover section

From: Jelte Jansen <[email-masked]>
Date: Thu, 04 Sep 2008 11:50:33 +0200

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 RFC4From [email-masked]  Thu Sep  4 02:50:33 2008
Date: Thu, 04 Sep 2008 11:50:33 +0200
From: Jelte Jansen <[email-masked]>
To: [email-masked]
Subject: [DNSOP] suggestion for 4641bis: key algorithm rollover section
Sender: [email-masked]

This is a multi-part message in MIME format.

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 RFC403035, 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

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 oy��.�ا�)�z7��*'��ay֭ih^���������֥��������k��^�Ƨ��.�^��^�('j۫zǱ�*ފ{ayƜ���~�޶�{+�8b�Ƨm�kz����[�z-i�b�
+�騾)�n�a��{+��azȠ��n����^����)�>�)�ǝi�b�*'���s���؟}�mi�^v)��h��-��m��^�ج��fjx%y��)��W%���"٢�gy�Zn+f���~�^����z�+��b�{a��!|������	z[^A�4�H��5W��*'{��x�Z�x�
��z{T�)�{����3�YZ��i����	��Y��ׯ��"�D@��@�/�ـ�D8����ӧqOE((E���#��S���\�q'��0@($.�4���ié΅|��lS(o��43�="4�D

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"bF�R���R�2�WfW"'&��V�ࠠ

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 04 Sep 2008 23:06:05 +1000

It's not a issue.  You remove the DS's which have that
	algorithm then once they have expired from caches you can
	remove the DNSKEY.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Thu, 04 Sep 2008 23:06:05 +1000

Mark

---

From: Jelte Jansen <[email-masked]>
Date: Thu, 04 Sep 2008 15:33:06 +0200

> 	algorithm then once they have expired from caches you can

That could still leave the zone itself in an inconsistent state... I'm
not talking about the DS<->child apex case, but the apex<->zone data case.

The DNSKEY that is removed or added doesn't have to be one that is
pointed to by a DS. Merely being present in the apex implies that there
should be signatures of that algorithm in the zone.

If you don't add/remove all keys at the same time, the first or last
DNSKEY couldn't even be a KSK; since those keys aren't used to sign the
zone data, having a KSK as the only key of a certain algorithm number
would always violate section 2.2.

Unless of course I am misreading that MUST there :)

Jelte

---

From: Jelte Jansen <[email-masked]>
Date: Thu, 04 Sep 2008 15:33:06 +0200

Jelte

---

From: Mark Andrews <[email-masked]>
Date: Thu, 04 Sep 2008 23:52:57 +1000

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mark Andrews wrote:

	If there is a DS with algorithm A then you have to have the
	entire zone signed with that algorithm.  Once the DS has gone
	then that requirement no longer exists.
	
> should be signatures of that algorithm in the zone.

	No.  The DS / published trust anchor indicates support for
	the algorithm.  Just having a DNSKEY at the apex does not
	indicate support for a algorithm.

	Mark
 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (FreeBSD)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAki/444ACgkQ4nZCKsdOncVoEACg2XThBDfSoUosRQBUTDcL2jYg
> bKkAoKNU4hLa/s5/xPlGVQp6XKXV7Uyv
> =TLej
> -----END PGP SIGNATURE-----
-- 
MarFrom [email-masked]  Thu Sep  4 06:52:56 2008
To: Jelte Jansen <[email-masked]>
From: Mark Andrews <[email-masked]>
Date: Thu, 04 Sep 2008 23:52:57 +1000
Cc: [email-masked]
Subject: Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section
Sender: [email-masked]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mark Andrews wrote:

	If there is a DS with algorithm A then you have to have the
	entire zone signed with that algorithm.  Once the DS has gone
	then that requirement no longer exists.
	
> should be signatures of that algorithm in the zone.

	No.  The DS / published trust anchor indicates support for
	the algorithm.  Just having a DNSKEY at the apex does not
	indicate support for a algorithm.

	Mark
 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (FreeBSD)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAki/444ACgkQ4nZCKsdOncVoEACg2XThBDfSoUosRQBUTDcL2jYg
> bKkAoKNU4hLa/s5/xPlGVQp6XKXV7Uyv
> =TLej
> -----END PGP SIGNATURE-----
-- 
Mark k Andrews, ISC

Andrews, ISC

---

From: Dean Anderson <[email-masked]>
Date: Thu, 4 Sep 2008 11:34:42 -0400 (EDT)

> 	algorithm then once they have expired from caches you can

Of course, you can replay them, resulting in a DOS.  (I'll call 
this attack 6)

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Dean Anderson <[email-masked]>
Date: Thu, 4 Sep 2008 11:34:42 -0400 (EDT)

--Dean

---

From: Scott Rose <[email-masked]>
Date: Sat, 6 Sep 2008 15:46:54 -0400

(resent due to list hiccups - if anyone gets multiple messages, I  
apologize)

I would also mention in the text that this problem applies to a zone  
migrating from NSEC to NSEC3 (when using RSA/SHA-1)  The algorithm  
code is used to signal it so it would appear to resolvers as two  
different algorithms.

Scott

On Sep 4, 2008, at 5:50 AM, Jelte Jansen wrote:

> in RFC4035, resulting in rejection of the data.
>
> iEYEARECAAYFAki/r2YACgkQ4nZCKsdOncU9FACgoDkXP0PUjrdZTiJmiXNpxJ8X
> oMEAoJBougDT51O6MacOpzoV8/5ZsUyg
> =ab7S
> the integrity of the zone is never broken.
>

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
===================================

---

From: Scott Rose <[email-masked]>
Date: Sat, 6 Sep 2008 15:46:54 -0400

Scott