security DNS security and key ceremonies

[Future Sensors]

DNS security and key ceremonies

This post will focus on a key part of DNSSEC infrastructure — Root KSK ceremonies. These ceremonies exist to provide transparency to the Internet community around the creation, use, and storage of the Root KSK. Transparency is essential in establishing trust of the KSK — asking the Internet to just blindly trust something wouldn’t work, and rightly so!​

Read more:

https://blog.apnic.net/2021/10/12/dns-security-and-key-ceremonies/

 

[Bob Hawkes]

Wow I had no idea of all this. Thanks for sharing @Future Sensors .

I liked this: “So, in a sense, there is a group of seven people with ‘keys to the Internet’, but on their own, without ICANN (and the tens-of-thousands-strong Internet community backing them), they’re powerless.”

 

[Future Sensors]

Wow I had no idea of all this. Thanks for sharing @Future Sensors .

I liked this: “So, in a sense, there is a group of seven people with ‘keys to the Internet’, but on their own, without ICANN (and the tens-of-thousands-strong Internet community backing them), they’re powerless.”

So true. With SOA serial 2010071501 (July 2010) the DNS root was officially signed. The procedures have been polished since then, and trusted community representatives are selected from different geographic locations to avoid imbalance. Before the root was signed, there was a system that imitated a signed root: DNSSEC Lookaside Validation (DLV), which can be found in https://datatracker.ietf.org/doc/html/rfc5074

 

[Future Sensors]

Root Zone KSK Ceremony #1

The first Key Signing Key (KSK) generation ceremony for the DNS Root Zone. In a sense, the KSK represents the "master key" that is anticipated to be used from July 2010 to secure the root of the DNS system.

Taken on June 16, 2010
by Kim Davies

CC BY-NC-ND 2.0 license

Full album:
Root Zone KSK Ceremony #1
https://www.flickr.com/photos/kjd/albums/72157624302045698

 

[Future Sensors]

Rest In Peace, Dan Kaminsky (February 7, 1979 – April 23, 2021)

Best known for discovering a fundamental flaw in DNS in 2008.

https://en.wikipedia.org/wiki/Dan_Kaminsky#Flaw_in_DNS

https://www.blackhat.com/presentati...BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf

https://dankaminsky.com/

https://twitter.com/dakami

This photo is from the same Root Zone KSK Ceremony.

Taken on June 16, 2010
by Kim Davies

CC BY-NC-ND 2.0 license

 

[Future Sensors]

 

[Future Sensors]

https://www.iana.org/dnssec/ceremonies/44

 

[Future Sensors]

 

[Future Sensors]

Verisign's role in securing the DNS through Key Signing Ceremonies​

https://blog.verisign.com/security/verisign-dns-key-signing-ceremony/

 

[Future Sensors]

During ICANN76 there was a special DNS Women Session.

ICANN's Marilia Hirano encouraged more women to apply and become Trusted Community Representatives, and explained why it is essential for the DNS technical community to be involved in key aspects of managing the Root Zone Key Signing Key.

The criteria for becoming a Trusted Community Representative can be found on the IANA website.

See also: https://www.dnswomen.org/about/

 

[Future Sensors]

DNSSEC Key Signing Suite Documentation

https://github.com/NLnetLabs/dnssec-ceremony-doc

Copyright (c) 2019-2020 NLnet Labs
Released under Creative Commons CC 4.0 BY-SA

Preamble

The Domain Name System Security Extensions (DNSSEC) increase trust in the Domain Name System (DNS) by adding authenticity and integrity to the protocol. While originally designed to improve the security of the DNS alone, with the advent of DNS-based Authentication of Named Entitities (DANE) DNSSEC is increasingly used to improve trust in other Internet services (such as, e.g., e-mail).

The root of the trust in DNSSEC is vested in the cryptographic keys that are used to sign DNS zones. For operators of high-value domains - such as, for example, top-level domains, governmental domains or high-value enterprise domains - it is important to handle this sensitive DNSSEC key material securely. While there exists a plethora of approaches to managing DNSSEC key material, often highly specific to the environment in which they are deployed, there is no generic approach, nor an overview of requirements or best practices.

The goal of the DNSSEC Key Signing Suite project is to provide such a generic approach, and in particular, to describe an approach for so-called "offline KSKs", where the Key Signing Key for a domain is kept offline and only used during special key signing ceremonies to sign the DNSKEY record sets for a number of future Zone Signing Keys (ZSKs). We break this down into two parts: 1) an operational part in the form of a key signing ceremony that can be tailored to the specific needs of an environment and 2) a set of UNIX command-line tools that can support this ceremony at various stages.

Audience and Scope

The audience for this project consists of managers and engineers involved in the management of high-value domains (such as, but not limited to, top-level domains, governmental domains, ...). Readers are assumed to be familiar with DNSSEC and its terminology.

The scope of this project's documentation is limited to DNSSEC key ceremonies and technical key management. DNSSEC signer operations are out of scope, although certain DNSSEC and DNS parameters are required as input to certain parts of the ceremony and may need to be specified to the technical key management tools.

Reading Guide

This repository contains the following documents:

• CEREMONY.md - this document describes what to take into consideration when designing a ceremony and provides boiler plate approaches to the various stages. We recommend that you at least read the section on considerations before choosing an approach to your own key ceremony.
• RECIPE-API.md - this document contains an API description for the commands that are exchanged between a signer system and the protected environment in which the key ceremonies will take place (which we colloquially refer to as the "bunker").

 

[Future Sensors]

Root Zone KSK HSM Update

April 13, 2023

Recently we became aware of a decision by the manufacturer of our hardware security modules (HSMs) to cease production of the devices. Further, there is no successor product as they are exiting that line of business[1].

The Keyper products we use were in part selected as they were the only viable device that met FIPS 140-2 Level 4 certification, the highest certification possible. They do not provide a function that would allow the private key to be exported and imported into an alternative vendor’s device.

This news came after we announced last month that we are intending the generate the next Root Zone KSK during our ceremony later this month. That key is planned for production use from 2025-2029 approximately.

In light of the news of the HSMs, our plan is as follows:

• We are commencing a comprehensive analysis of the options available for KSK storage into the future. We understand that may involve adaptations to the security model, and once we’ve identified our preferred plan of action, we will consult on any implications of the new vendor selection.
• We plan to continue to generate the next KSK this year. We expect the need to switch HSMs may either alter the timeframe it is in production, or may pre-empt rolling to that key completely. However if we do not generate the next KSK, it limits the options available to us in the future.
• We are working with the vendor to ensure we have the best capability to continue to utilise the current HSMs for the next five years at least. This includes procuring additional spares and exploring options for reconditioning units with new batteries and the like.

We’re happy to answer any questions and we’ll keep you posted as circumstances evolve. Obviously the HSM is at the heart of the security of the KSK so we will be devoting significant resources to this development in the coming year.

[1] https://www.ultra.group/media/3747/20230306-end-of-life-notice-for-ultra-keyperplus.pdf

Kim Davies
VP, IANA Services, ICANN
President, PTI