dnssec for the root zonednssec for the root zone nznog hamilton, nz january 2010 joe abley, icann...

DNSSECfor the Root Zone

NZNOG Hamilton, NZJanuary 2010

Joe Abley, ICANNJoe Abley, ICANN

Thursday 28 January 2010

This design is the result of a cooperation between ICANN & VeriSign withsupport from the U.S. DoC NTIA

Design

Design RequirementsKeywords

Transparency Processes and procedures should

be as open as possible for the Internetcommunity to trust the signed root

Audited Processes and procedures should

be audited against industry standards,e.g. ISO/IEC 27002:2005

High SecurityRoot system should meet all NIST

SP 800-53 technical security controls required by a HIGH IMPACT system

Roles and Responsibilities

ICANNIANA Functions Operator

• Manages the Key Signing Key (KSK)

• Accepts DS records from TLD operators

• Verifies and processes request

• Sends update requests to DoC for authorization and to VeriSign for implementation

DoC NTIAU.S. Department of Commerce

National Telecommunications and Information Administration

• Authorizes changes to the root zone

‣ DS records

‣ Key Signing Keys

‣ DNSSEC update requests follow the same process as other changes

• Checks that ICANN has followed their agreed upon verification/processing policies and procedures

VeriSignRoot Zone Maintainer

• Manages the Zone Signing Key (ZSK)

• Incorporates NTIA-authorized changes

• Signs the root zone with the ZSK

• Distributes the signed zone to the root server operators

ICANN VeriSign

DoCRZM SignerTLDOperator Signed root

KSK Management

DNS records sent fromTLD operator to ICANN

Verified datasent to DoC

Authorized datasent to VeriSign

ZSK sent from VeriSign to ICANN

Root Zonedistributed toroot servers

ZSK Management

Root Servers

KSK publishedby ICANN

Keyset is signed by KSK and sent back from ICANN to VeriSign

Unsigned root

Approach to Protecting the KSK

Facility – Tier 1 – Access control by Data Center

Cage – Tier 4 – Access control by Data Center

Safe Room – Tier 5 – Access control by ICANN

Safe #1 – Tier 6

HSM – Tier 7

Private Keys Key Ceremony Computer

Safe #2 – Tier 6

Safe Deposit Box – Tier 7

Crypto Officers' Credentials

Physical Security

DPSDNSSEC Practice Statement

• States the practices and provisions that are employed in root zone signing and zone distribution services

‣ Issuing, managing, changing and distributing DNS keys in accordance with the specific requirements of the U.S. DoC NTIA

• Comparable to a certification practice statement (CPS) from an X.509 certification authority (CA)

Key Signing Key Management

Generate

Publish

Destroy

ICANN Staff

ExternalTrusted Persons

Global Internet Community 3rd Party Auditors

Policy & Practice Statement

Zone Signing Key Management

Generate

Publish

Destroy

VeriSign Staff

3rd Party Auditors

Policy & Practice Statement

Other Witnesses

Community Trust

• Proposal that Community Trusted Representatives (TCR) have an active roll in management of the KSK

‣ as Crypto Officers needed to activate the KSK

‣ as Recovery Key Share Holders protecting shares of the symmetric key that encrypts the backup copy of the KSK

Crypto Officers

Keys to safe deposit boxesheld by Crypto Officers

Crypto officer credentials storedon-site in safe deposit boxes

7 Crypto Officercards generated atHSM initialization

CO Card #1

CO Card #2

CO Card #3

CO Card #4

CO Card #5

CO Card #6

CO Card #7

Crypto Officer #1

Crypto Officer #2

Crypto Officer #3

Crypto Officer #4

Crypto Officer #5

Crypto Officer #6

Crypto Officer #7

Authorisation Key – AAK

≥ 3 Crypto Officer cardsneeded for key use

Key Backup

Keys to safe deposit boxesheld by trusted persons

Key shares stored off-sitein safe deposit boxes in

separate locations

RK split into7 key shares at

HSM initialization

Key Share #1

Key Share #2

Key Share #3

Key Share #4

Key Share #5

Key Share #6

Key Share #7

Share Holder #1

Share Holder #2

Share Holder #3

Share Holder #4

Share Holder #5

Share Holder #6

Share Holder #7

≥ 5 key shares neededto restore RK in case

of HSM failure

Recovery key is used to encryptthe KSK before backup

Root KSK

Recover Key (RK)

ICANN on-site backup

KSK Encrypted by RK

Auditing & Transparency

• Third-party auditors check that ICANN operates as described in the DPS

• Other external witness may also attend the key ceremonies

DNSSECProtocol Parameters

Key Signing Key

• KSK is 2048-bit RSA

‣ Rolled every 2-5 years

‣ RFC 5011 for automatic key rollovers

• Propose using signatures based on SHA-256

Zone Signing Key

• ZSK is 1024-bit RSA

‣ Rolled once a quarter (four times per year)

• Zone signed with NSEC

• Propose using signatures based on SHA-256

Signature Validity

• DNSKEY-covering RRSIG (by KSK) validity 15 days

‣ new signatures published every 10 days

• Other RRSIG (by ZSK) validity 7 days

‣ zone generated and resigned twice per day

Key Ceremonies

• Key Generation

‣ Generation of new KSK

‣ Every 2-5 years

• Processing of ZSK Signing Request (KSR)

‣ Signing ZSK for the next upcoming quarter

‣ Every quarter

KSR Processing

KSR transport protected using TLS with client-side authentication

ZSK signs DNSKEYsinside KSR

KSK signs DNSKEYsinside SKR

KSK ZSK

ICANNCertificate Authority

VeriSignCertificate Authority

Key Signing Request

Signed Key Response Signer

RootZone

Ceremony Administrator

ZSKAdministrator

ICANN CA issuescert for TLS

VeriSign CA issuescert for TLS

Out-of-band integrity verification of KSRat the key ceremony

VeriSign publish thesigned root via root servers

KSR Processing

KSK ZSK

Key Signing Request

RootZone

ZSKAdministrator

KSR Processing

KSK ZSK

Key Signing Request

RootZone

ZSKAdministrator

KSR Processing

KSK ZSK

Key Signing Request

RootZone

ZSKAdministrator

KSR Processing

KSK ZSK

Key Signing Request

RootZone

ZSKAdministrator

Key Schedule

T+90T+80T+70T+60T+50T+40T+30T+20T+10T+0T-10

Quarterly time cycle is ~ 90 days

Key Schedule

T+90T+80T+70T+60T+50T+40T+30T+20T+10T+0T-10

ZSK rollover

ZSKpre-publish ZSK

ZSKZSKZSKZSKpre-publish ZSK ZSK ZSKZSK ZSK ZSK

post-publishZSK

ZSKpost-publishZSK

Key Schedule

T+90T+80T+70T+60T+50T+40T+30T+20T+10T+0T-10

ZSK rollover

ZSKpre-publish ZSK

post-publishZSK

ZSKpost-publishZSK

Optional KSK rollover

KSKpublish

KSKpublish+sign

KSKpublish

KSK revoke+sign

KSKpublish+sign

Key Schedule

T+90T+80T+70T+60T+50T+40T+30T+20T+10T+0T-10

ZSK rollover

ZSKpre-publish ZSK

post-publishZSK

ZSKpost-publishZSK

KSKpublish

KSKpublish+sign

KSKpublish

KSK revoke+sign

KSKpublish+sign

Key Schedule

T+90T+80T+70T+60T+50T+40T+30T+20T+10T+0T-10

ZSK rollover

ZSKpre-publish ZSK

post-publishZSK

ZSKpost-publishZSK

KSKpublish

KSKpublish+sign

KSKpublish

KSK revoke+sign

KSKpublish+sign

Key Schedule

T+90T+80T+70T+60T+50T+40T+30T+20T+10T+0T-10

ZSK rollover

ZSKpre-publish ZSK

post-publishZSK

ZSKpost-publishZSK

KSKpublish

KSKpublish+sign

KSKpublish

KSK revoke+sign

KSKpublish+sign

Key Schedule

T+90T+80T+70T+60T+50T+40T+30T+20T+10T+0T-10

ZSK rollover

ZSKpre-publish ZSK

post-publishZSK

ZSKpost-publishZSK

KSK revoke+sign

KSKpublish+sign

KSK removal

Root Trust Anchor

• Published on a web site by ICANN as

‣ XML-wrapped and plain DS record

• to facilitate automatic processing

‣ PKCS #10 certificate signing request (CSR)

• as self-signed public key

• Allows third-party CAs to sign the KSK

• ICANN will sign the CSR producing a CERT

Deployment

• Deploy a signed root zone

‣ Transparent processes

‣ Audited procedures

‣ DNSSEC deployment

• validators, registries, registrars, name server operators

• Communicate early and often!

Anticipated Issues

• A significant proportion of DNS clients send queries with EDNS0 and DO=1

• Some (largely unquantified, but potentially significant) population of such clients are unable to receive large responses

• Serving signed responses might break those clients

Rollback

• If we sign the root, there will be some early validator deployment

• There is the potential for some clients to break, perhaps badly enough that we need to un-sign the root (e.g., see previous slide)

• Un-signing the root will break the DNS for validators

Staged Deployment

Deploy Incrementally• Serve a signed zone from just L-Root,

initially

• Follow up with A-Root

• Then other root servers

‣ M, I

‣ D, K E,

‣ B, H, C, G, F

• Last, J-Root

Deploy Incrementally

• The goal is to leave the client population with some root servers not offering large responses until the impact of those large responses is better understood

• Relies upon resolvers not always choosing a single server

• “Deliberately Unvalidatable Root Zone”

• Sign RRSets with keys that are not published in the zone (but with matching keytag…)

• Publish keys in the zone which are not used, and which additionally contain advice for operators (see next slide)

• Swap in actual signing keys (which enables validation) at the end of the deployment process

. 3600 IN DNSKEY 257 3 5 ( AwEAAa++++++++++++++++++++++++++++++ ++THIS/KEY/AN/INVALID/KEY/AND/SHOULD /NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICA NN/DOT/ORG/FOR/MORE/INFORMATION+++++ ++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++/= ) ; Key ID = 6477

• Deploy conservatively

‣ It is the root zone, after all

• Prevent a community of validators from forming

‣ This allows us to unsign the root zone during the deployment phase (if we have) to without collateral damage

Measurement

• For those root servers that are instrumented, full packet captures and subsequent analysis around signing events

• Ongoing dialogue with operator communities to assess real-world impact of changes

Testing

• A prerequisite for this proposal is a captive test of the deployment

‣ Test widely-deployed resolvers, with validation enabled and disabled, against the DURZ

‣ Test with clients behind broken networks that drop large responses

Interaction with TLDs

DS Change Requests

• Approach likely to be based on existing methods for TLD managers to request changes in root zone

• Anticipate being able to accept DS requests 1-2 months before the validatable signed root zone is in production

• Current topic of discussion within Root DNSSEC Design Team

Communication

Project Web Page

• http://www.root-dnssec.org

‣ Status updates

‣ Documents

‣ Presentation Archive

‣ Small collection of links to relevant tools

‣ Contact information

‣ RSS

Communicationwith non-technical audiences

• Will reach the non-technical and semi-technical audiences with press releases and other means.

• PR departments with people who know how to do this will be engaged.

Communicationwith technical audiences

• Reaching the technical audiences via mailing lists and other means

‣ IETF DNS lists (e.g. DNSOP)

‣ non-IETF DNS lists (e.g. DNS-OARC)

‣ General operator lists (e.g. NANOG)

‣ …

Draft Timeline• December 1, 2009

‣ Root zone signed

• Initially signed zone stays internal to ICANN and VeriSign

‣ ICANN and VeriSign begin KSR processing

• ZSK and KSK rolls

• January - July 2010

‣ Incremental roll out of signed root

• July 1, 2010

‣ KSK rolled and trust anchor published

‣ Signed root fully deployed

Deployment Status25 January 2010

Documentation

• Requirements document posted

• High-Level Architecture, Policy and Practice Statements, Trust Anchor Publication, Deployment documents posted in draft form

• Ceremony, KSK Facility Requirements, Testing documents expected to be posted soon

http://www.root-dnssec.org

Testing

• Several rounds of data collection testing by Root Server Operators complete

• Several KSR/SKR exchanges complete

• DURZ vs. Resolver testing complete

DURZ Roll-Out

• L-Root scheduled to start serving the root zone during the posted maintenance window 2010-01-27 1800-2000 UTC

Thoughts?

• Feedback on this proposal would be extremely welcome

‣ Email to rootsign@icann.org

Root DNSSEC Design Team

Joe AbleyMehmet AkcinDavid BlackaDavid ConradRichard LambMatt Larson

Fredrik LjunggrenDavid Knight

Tomofumi OkuboJakob Schlyter

dnssec for the root zonednssec for the root zone nznog hamilton, nz january 2010 joe abley, icann...

Documents

root meristem, root cap, and root

dns reﬂection attacks - network startup resource...

abley stephen marcel_and_the_white_star

cmq220 root cause analysis lesson 7 -root cause analysis...

1 nznog 2006 – victoria university wellington, march 23...

root locus method. root locus method root locus method

root root tip root hairs plant anatomy - rvrhs

nznog ’07 ‘dealing with joe jobs’ or how to cope with...

chapter 2: device driver basis - packt publishing ·...

roots, root system, root structure, root cap & root...

root, root, root for root beer!€¦ · through in several...

1 apnic update. 2 4th time at nznog … let’s do something...

root insurance (root) - citron research

1 update of what’s happening within apnic nznog ‘07...

root n4e8g6vb9te7c2j root 7enkef24379018k root...

high-level awareness of dnssec kenic/nsrc workshop, nairobi,...

encryption with dane, nznog 2017

dns session 5 additional topics joe abley afnog 2006,...

1 nznog 2007 – inspire.net / massey university, palmerston...

nznog 2018: apnic whois and policy update