[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
- [DNSOP] suggestion for 4641bis: key algorithm rol… Jelte Jansen
- Re: [DNSOP] suggestion for 4641bis: key algorithm… Mark Andrews
- Re: [DNSOP] suggestion for 4641bis: key algorithm… Jelte Jansen
- Re: [DNSOP] suggestion for 4641bis: key algorithm… Mark Andrews
- Re: [DNSOP] suggestion for 4641bis: key algorithm… Dean Anderson
- Re: [DNSOP] suggestion for 4641bis: key algorithm… Jelte Jansen
- Re: [DNSOP] suggestion for 4641bis: key algorithm… Jelte Jansen
- Re: [DNSOP] suggestion for 4641bis: key algorithm… Jelte Jansen
- Re: [DNSOP] suggestion for 4641bis: key algorithm… Jelte Jansen
- Re: [DNSOP] suggestion for 4641bis: key algorithm… Scott Rose