DNSSEC Trust Anchor History Service
draft-wijngaards-dnsext-trust-history-02

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 6, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

When DNS validators have trusted keys, but have been offline for a longer period, key rollover will fail and they are stuck with stale trust anchors. History service allows validators to query for older DNSKEY RRsets and pick up the rollover trail where they left off.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

1.  Introduction

DNSSEC [RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.) validators that have been offline of have missed an (emergency) rollover can use trust history service to get back on track. The trust history location is assumed available from the validator configuration. The validator then fetches old DNSKEY RRsets and checks they form a chain to the latest key.

Providers of trust history can fetch the DNSKEY data as published by the zone they track, and copy-and-paste it. They need not sign nor hold private keys safe. The algorithms for this are explained below.

2.  Trust History Lookup

The algorithm is in steps.

Step 1. The validator performs a DNSKEY lookup to the target zone, which looks like any other initial DNSKEY lookup for a trust anchor. If the keyset verifies with the trust anchor currently held, the keyset already works. Otherwise, store this result, the further algorithm either ends with this result or fails.

Step 2. Fetch the trust history list end points. Query type PTR to the location configured for trust history.

Step 3. Go backwards through the trust history list. Verify that the keyset validly signs the next keyset. This is [RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.) validation, but the RRSIG expiration date is ignored. Replace the owner domain name of the DNSKEY with the target zone name for verification. Query type PTR to get previous and next locations.

Step 4. When the trust anchor currently held by the validator verifies the keyset, the algorithm is done. The initial DNSKEY from Step 1 is the result. Use it as the new trust anchor (if using [RFC5011] (StJohns, M., “Automated Updates of DNS Security (DNSSEC) Trust Anchors,” September 2007.), put it in state VALID). The validator SHOULD store the new trust anchor on stable storage.

3.  Trust History Tracker

The tracker polls the target zone DNSKEY RRset from cron. Ignore date changes in the RRSIG. If the tracker knows that the zone performs responsible prepublish KSK rollovers [RFC4641] (Kolkman, O. and R. Gieben, “DNSSEC Operational Practices,” September 2006.) then also ZSK changes can be ignored.

Copy the newly polled DNSKEY RRset and RRSIGs, change the owner name to "h%d.example" or similar. With %d a new number, and .example the history location. Publish the new RRset. Publish PTR records that link list elements. Update PTR records for the list start and end.

The list is a double linked list, because this empowers low memory hosts to perform consistency checks. Thus if there is x.example PTR y.example then there MUST be y.example PTR x.example. Except at start and end of list.

To find the start of the list, it MUST be a name before the end of the list in canonical comparison ordering ([RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.)). With exactly one list element, one PTR record points to both start and end.

4.  Example

In this example tuhi.example.com provides trust history for example.net. The DNSKEY rdata and RRSIG rdata is omitted for brevity, it is a literal copy and paste of the data from example.net.

$ORIGIN tuhi.example.com.
@ PTR h0
@ PTR h2

h0 PTR h1
h0 DNSKEY ...
h0 RRSIG ...

h1 PTR h2
h1 PTR h0
h1 DNSKEY ...
h1 RRSIG ...

h2 DNSKEY ...
h2 RRSIG ...
h2 PTR h1

5.  Security Considerations

The trust history tracker only provides a cached copy of old data. The history data can be altered or withheld; the lookup algorithm then fails.

Ultimately the security depends on the key that the validator is holding, and the keys in the chain up to the present. If the old key held by the validator is too old, the validator MAY not accept this risk, and then SHOULD perform out of band key priming.

The algorithm looks up the initial DNSKEY like other validators do, and then walks the history in reverse. This avoids exposing the validator on the network as a host with an older key and the key id.

Validators can (OPTIONAL) examine RRSIG dates. To account for clock skew padding by the target zone, the middle of the inception and expiration date SHOULD be used, if consistency checks are done.

The algorithm can be abused to provide a secure method to get (close to) the current month or year. Validators without clock then know the date that validates signatures currently in use by the zone.

6.  IANA Considerations

-

7.  References

7.1. Informative References

7.2. Normative References

Author's Address