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

Jelte Jansen <jelte@NLnetLabs.nl> Thu, 04 September 2008 09:50 UTC

Return-Path: <dnsop-bounces@ietf.org>
X-Original-To: dnsop-archive@optimus.ietf.org
Delivered-To: ietfarch-dnsop-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343903A6B8B; Thu, 4 Sep 2008 02:50:33 -0700 (PDT)
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305FA3A6B8B for <dnsop@core3.amsl.com>; Thu, 4 Sep 2008 02:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDvQrCIbUK4l for <dnsop@core3.amsl.com>; Thu, 4 Sep 2008 02:50:31 -0700 (PDT)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id D48A63A6B89 for <dnsop@ietf.org>; Thu, 4 Sep 2008 02:50:30 -0700 (PDT)
Received: from mirre.nlnetlabs.nl (mirre.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:fe0b:89f4]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m849oXuQ069900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <dnsop@ietf.org>; Thu, 4 Sep 2008 11:50:34 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl)
Message-ID: <48BFAF69.1010604@NLnetLabs.nl>
Date: Thu, 04 Sep 2008 11:50:33 +0200
From: Jelte Jansen <jelte@NLnetLabs.nl>
User-Agent: Thunderbird 2.0.0.16 (X11/20080826)
MIME-Version: 1.0
To: dnsop@ietf.org
X-Enigmail-Version: 0.95.2
Content-Type: multipart/mixed; boundary="------------050500060304000209060001"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 04 Sep 2008 11:50:34 +0200 (CEST)
Subject: [DNSOP] suggestion for 4641bis: key algorithm rollover section
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
Sender: dnsop-bounces@ietf.org
Errors-To: dnsop-bounces@ietf.org

-----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 RFC4From dnsop-bounces@ietf.org  Thu Sep  4 02:50:33 2008
Return-Path: <dnsop-bounces@ietf.org>
X-Original-To: dnsop-archive@lists.ietf.org
Delivered-To: ietfarch-dnsop-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 343903A6B8B;
	Thu,  4 Sep 2008 02:50:33 -0700 (PDT)
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 305FA3A6B8B
	for <dnsop@core3.amsl.com>; Thu,  4 Sep 2008 02:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id RDvQrCIbUK4l for <dnsop@core3.amsl.com>;
	Thu,  4 Sep 2008 02:50:31 -0700 (PDT)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1])
	by core3.amsl.com (Postfix) with ESMTP id D48A63A6B89
	for <dnsop@ietf.org>; Thu,  4 Sep 2008 02:50:30 -0700 (PDT)
Received: from mirre.nlnetlabs.nl (mirre.nlnetlabs.nl
	[IPv6:2001:7b8:206:1:219:d1ff:fe0b:89f4]) (authenticated bits=0)
	by open.nlnetlabs.nl (8.14.2/8.14.2) with ESMTP id m849oXuQ069900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <dnsop@ietf.org>; Thu, 4 Sep 2008 11:50:34 +0200 (CEST)
	(envelope-from jelte@NLnetLabs.nl)
Message-ID: <48BFAF69.1010604@NLnetLabs.nl>
Date: Thu, 04 Sep 2008 11:50:33 +0200
From: Jelte Jansen <jelte@NLnetLabs.nl>
User-Agent: Thunderbird 2.0.0.16 (X11/20080826)
MIME-Version: 1.0
To: dnsop@ietf.org
X-Enigmail-Version: 0.95.2
Content-Type: multipart/mixed; boundary="------------050500060304000209060001"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0
	(open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]);
	Thu, 04 Sep 2008 11:50:34 +0200 (CEST)
Subject: [DNSOP] suggestion for 4641bis: key algorithm rollover section
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:dnsop-request@ietf.org?subject=subscribe>
Sender: dnsop-bounces@ietf.org
Errors-To: dnsop-bounces@ietf.org

This is a multi-part message in MIME format.
-----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 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
-----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-----
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop