ENUM DNSSEC Key Maintenance Procedure

Introduction

One of the main issues for early deployment of DNSSEC is key distribution and maintenance. A key pair has been created for the ENUM (e164.arpa) zone. The private part of that key pair is used to sign the zone, while the public key needs to be distributed to the DNS client. This means validating recursive name servers to validate the data. DNSSEC allows public key distribution through the DNS, but this will only work if it is possible to build a chain of authority from a 'trust-anchor' through delegation from parent to child in each zone.

This 'trust-anchor' should ideally be the root. If there is no signed root, then all DNS clients that want to verify zone data will have to manually configure the zone keys, and maintenance of these keys is a process that does not scale well. The IETF is currently working on a solution to this issue.

Operators that configure 'trust-anchors' into their validating DNS clients will need to be conscientious about maintaining them. The 'trust-anchor' and the Key Signing Key (KSK) used to sign the zone must remain synchronised. If operators do not update their keys, then their zones might become invisible to DNS clients performing DNSSEC validation.

Signing Policy

To avoid possible failures, the RIPE NCC we will sign the e164.arpa zone according to the policy below:

• RIPE NCC will sign all data in the zone with at least one Zone Signing Key (ZSK); a ZSK is zone specific
• The ZSK will be published in the DNSKEY Resource Record (RR) set and signed with a Key Signing Key (KSK)
• The KSKs will have an SEP flag set so that they can be distinguished from the ZSKs in the DNSKEY RR set

Rollover Policy

• The ZSK may be rolled without making any announcement. This will be done according to the 'pre-publish rollover scheme' detailed below, which will avoid breaks in the chain of trust.
• During the first two years of deployment, the KSK of the e164.arpa zone will be rolled twice each year. The rollovers will be carried out according to the 'double signature scheme', as follows:
  • At t=0 KSK1 signs the keyset.
  • At t=3 months KSK1 and KSK2 sign the keyset. DNS clients are expected to configure KSK2 during the three months that follow.
  • At t=6 months only KSK2 signs the keyset until.
  • At t=9 months KSK3 is introduced and a new rollover starts.

Communications

The KSKs for the ENUM zone which is to be used as a 'trust-anchor' will be published on a secure website. We will follow the format used in the 'trusted-keys' statement in BIND9 named configuration files.

Changes to this procedure, as well as any other announcements from the RIPE NCC, will be signed with our PGP key and published on our secure website and the ENUM-WG mailing list.

All key rollover events will be announced one week in advance on the ENUM-WG mailing list.