Survey of Rollover Mechanisms
Thierry Moreau <thierry.moreau@connotech.com> Fri, 23 September 2005 16:31 UTC
From: Thierry Moreau <thierry.moreau@connotech.com>
Subject: Survey of Rollover Mechanisms
Date: Fri, 23 Sep 2005 12:31:26 -0400
Lines: 163
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-From: owner-namedroppers@ops.ietf.org Fri Sep 23 18:06:22 2005
Return-path: <owner-namedroppers@ops.ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: Namedroppers <namedroppers@ops.ietf.org>
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RCVD_IN_SBL autolearn=no version=3.0.2
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
X-Message-ID:
Message-ID: <20140418072050.2560.89024.ARCHIVE@ietfa.amsl.com>
Dear all: In order to assist the discussion, here is a survey of trust anchor key mechanisms. The 1 1/2 Internet drafts that are being discussed are in survey entries 2.a) and 2.b). Other entries do not appear in the current IETF agenda but may be relevant since they address the same rollover requirement. As a reminder, trust anchor key rollover relates to the need to change the KSK of a DNSSEC-aware DNS zone when the parent zone is DNSSEC-obvlious. It will apply to the root zone if and when it becomes DNSSEC-aware, and to "islands of trust" in the meantime. Trust anchor key rollover is a tough problem, linked ultimately to the trust anchor key initial distribution. Any rollover mechanism has a catastrophic failure mode, so there is no good solution: if a security incident falls in the catastrophic failure mode definition, the rollover mechanism becomes insecure and the trust anchor key initial distribution must be re-done. For now, I leave to the readers the task of identifying the catastrophic failure mode definition for each entry, but for the easiest one. 1. Outside Certification Description: outside certification relies on the digital signatures in a context different from the DNS hierarchy. In terms of security fundamentals, it shifts the "root" to some other set of rules. 1.a) Ben Laurie's "Distributing Keys for DNSSEC" use X.509 security certificates for outside certification of trust anchor keys. See reference [1]. 1.b) DLV is not presented as a rollover mechanism, but it does fit the definition of outside certification. DLV uses a "lookaside" digital signature by a "DLV operator" who more or less replaces the higher part of the DNSSEC hierarchy until "islands of trust" vanishes because the root and TLDs become DNSSEC-aware. For DNSSEC-aware resolvers, the DLV approach makes use of familiar DNSSEC protocol elements. See references [2] and [3]. 2. Plurality of trust anchor keys Description: with these two schemes, a trust anchor should be materialized with a set of public keys, and the rollover operation is done by the zone manager a subset at a time, so that the DNS resolvers can rely on the "not-rolled" keys to get confidence in the new keys. 2.a) The threshold mechanism being discussed currently in the DNSEXT working group, despite being an expired draft. See reference [4]. 2.b) The timing mechanism also discussed now in DNSEXT. See reference [5]. 3. Pre-announcement with plurality of digests Description: upon trust anchor key initial distribution, a list of cryptographic digests of future keys is distributed as well. The DNS resolvers validate a key rollover against the digest originally received. 3.a) The TAKREM mechanism, which I introducte to DNSEXT as a pre-draft document with discussion, rationales. See reference [6]. 3.b) The same TAKREM mechanism may be used with a "plain" hash function (e.g. SHA-1) instead of a parameterized one like MASH (ISO/IEC 10118-4:1998). 4. Long-lasting trust anchor keys Description: if no rollover method is found adequate, a long-lasting trust anchor key is an easy to specify method. With this method, any type of incident falls under the definition of catastrophic failure mode, while other methods leave some type of incidents in this category. 5. Out-of-band Validated Rollover Description: the "textbook" rollover method is to distribute the key to DNS resolvers and use an out-of- band channel to let the end-users validate the new key. There isn't the slightest chance that this is operationally feasible in any context. The out-of-band validated rollover method is documented to support the long-lasting trust anchor key method. The above survey is the easy part. The tough part is to determine what would be reasonable requirements for DNSSEC good fate, while no good solution exist. Thereafter, these requirements may, or might not, or might partly, be considered within the scope of the IETF mandate. For instance, the DLV promoters would like to have a DLV RR type assigned to the DLV method, but leave every other aspects of the specification outside of the IETF activities. Hope it helps. References: [1] Ben Laurie, "Distributing Keys for DNSSEC"draft-laurie-dnssec-key-distribution-00, September 30, 2004 [2] Mark Andrews, Sam Weiler, "The DNSSEC Lookaside Validation (DLV) DNS Resource Record" draft-andrews-dlv-dns-rr-00 June 23, 2005 [3] Sam Weiler, "DNSSEC Lookaside Validation (DLV)" 22 May 2005, http://www.watson.org/~weiler/dlv/ draft-weiler-dnssec-dlv-pre00.txt [4] J. Ihren, O. Kolkman, B. Manning, "An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for DNSSEC Trust Anchors", draft-ietf-dnsext-trustupdate-threshold-00, October 18, 2004 [5] Mike StJohns, "Automated Updates of DNSSEC Trust Anchors", draft-ietf-dnsext-trustupdate-timers-01, August 15, 2005 [6] Thierry Moreau, "'Trust Anchor' Integrity Mechanisms for Internet DNS Security" 2005/08/24 http://www.connotech.com/takrem_for_dnssec_01.pdf -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>
- Survey of Rollover Mechanisms Thierry Moreau
- Re: Survey of Rollover Mechanisms Olaf M. Kolkman