Anne-Marie Eklund LöwinderChief Information Security Officer

amel@iis.seTwitter: amelsechttp://www.iis.se

Thank’s to Fredrik Ljunggren, Kirei & Mehmet Akcin, ICANN

Signing the root with DNSSEC

How did it all begin?Walking down Memory Lane!

1983

Paul Mockapetris invents the DNS and implements the first server: Jeeves.

1986

Formal IETF Internet Standard. Two RFC's describes DNS: 1034 and 1035.

1990

Steven Bellovin describes cache poisoning for the first time, but the report is held back until 1995.

1997

RFC2065first version of the DNSSEC standard is published.

1999

RFC2535 is published, updating RFC2065.The DNSSEC protocol seems to be finally finished. BIND9 is developed to be the first DNSSEC capable implementation.

1999

Sequential transaction ID:Problems persisted.Multiple name server implementations usedsequential transaction ID’s, trivial to guess. (March)

2001

Experiments show that the key handling in RFC2535 is causing operational problems that would make deployment difficult, if not impossible. Redesigning is initiated.

2002

Multiple queries (November):Problems persisted in multipleimplementations.An attacker could generate several outstanding queries for the same data. Enabled spoofing through the birthday attack.

2002

Brains are working on it…

2003

Brains are working on it…

2004

Brains are working on it…

2005

Eureka!

The current RFC's are published:RFC4033, RFC4034, RFC4035

2005

Sweden (.SE) deploys DNSSEC..SE is the first TLD to adopt.

2006

Others are *thinking* about deploying DNSSEC…

2007

Others are *thinking* about deploying DNSSEC…

2007

Predictable RNG (July):Problems persisted, weaknesses in the PRNG’s (pseudo-random number generators) made guessing through statistical analysis feasible.Multiple implementations.

2008

Yet another flaw in the DNS protocol: The Kaminsky bug!

Targeting sibling names of a zone enabledinfinite number of retries for cache

poisoning.

2009

The Domain Name System desperately needs DNSSEC!Mending and patching obviously didn't do it…Others *are* deploying DNSSEC.

2010

The Root is signed since July 15, 2010!. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

DNSSEC in the root ties it all together and is an enabler for so much more.

Approach to DNSSEC in the root zone and protection of the KSK

Design

The guiding principle behind the design is that the result must be trustworthy.

Audited

Processes and procedures should be audited against industry standards e.g. ISO/IEC 27002:2005

High security

Root system should meet all NIST SP 800-53 technical security controls required by a HIGH IMPACT system.

Community involvement

Trusted representatives from the community are invited to take an active role in the key management process.

Terramark Data Center, Culpeper, VA

Physical security

Physical Security

Physical Security

More photos on http://dns.icann.org

Physical Security

• Enforced Dual Occupancy.

• Separation of Duties.

• External Monitoring.

• Video Surveillance.

• Motion, Seismic other Sensors

• …and more.

ICANN staff roles related to KSK ceremonies

• Ceremony Administrator (CA) is the staff member who runs the ceremony.

• Internal Witness (IW) is the ICANN staff witnessing and recording the ceremony and exceptions if any.

• System Administrator (SA) is technical staff members responsible of IT needs.

• Safe Security Controllers (SSC) are the ICANN staff who operates the safe.

DPS – DNSSEC 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 certificate practice statement (CPS) from an X.509 certification authority (CA).

• Compliant with http://tools.ietf.org/html/rfc6841 (as a number of other TLD’s are).

Auditing & Transparency

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

• Other external witness may also attend the key ceremonies.

• Systrust audit performed annualy.

Trusted Community Representatives (TCR)• Have an active role in the 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 Officer (CO)

• Have physical keys to safe deposit boxes holding smartcards that activate the HSM.

• ICANN cannot generate new keys or sign ZSK without 3-of-7 COs.

• Able to travel up to 4 times a year to US.

• So far the same people as from the start.

http://www.root-dnssec.org/tcr/selection-2010/

Recovery Key Share Holder (RKSH)• Have smartcards holding pieces (M-of-N) of the

key used to encrypt the KSK inside the HSM.

• If both key management facilities fall into the ocean, 5-of-7 RKSH smartcards and an encrypted KSK smartcard can reconstitute KSK in a new HSM.

• Backup KSK encrypted on smartcard held by ICANN.

• Able to travel on relatively short notice to US. Hopefully never. Annual inventory.

Community Representatives

• CO – East Coast• Alain Aina, BJ

• Anne-Marie Eklund Löwinder, SE

• Frederico Neves, BR

• Gaurab Upadhaya, NP

• Olaf Kolkman, NL

• Robert Seastrom, US

• Vinton Cerf, US

• CO – West Coast• Andy Linton, NZ

• Carlos Martinez, UY

• Dmitry Burkov, RU

• Edward Lewis, US

• João Luis Silva Damas, PT

• Masato Minda, JP

• Subramanian Moonesamy, MU

• CO Backup• Christopher Griffiths, US

• Fabian Arbogast, TZ

• John Curran, US

• Nicolas Antoniello, UY

• Rudolph Daniel, UK

• Sarmad Hussain, PK

• Ólafur Guðmundsson, IS

• RKSH• Bevil Wooding, TT

• Dan Kaminsky, US

• Jiankang Yao, CN

• Moussa Guebre, BF

• Norm Ritchie, CA

• Ondřej Surý, CZ

• Paul Kane, UK

• (6 BKP)

I’ve got the key to the Internet!

Split keys

• Zone Signing Key (ZSK) used to sign the zone.

• Key Signing Key (KSK) used to sign the ZSK.

• Not required by the protocol

Key Signing Key (KSK)

• KSK is 2048-bit RSA.• Rolled as required.

• RFC 5011 for automatic key rollovers.

• Signatures made using SHA-256.

Zone Signing Key (ZSK)

• ZSK is 1024-bit RSA.• Rolled once a quarter (four times per year).

• Zone signed with NSEC.

• Signatures made using SHA-256.

Key Ceremonies

• Key Generation.• Generation of new KSK.

• Processing of ZSK Signing Request (KSR).• Signing ZSK for the next upcoming quarter.

• Quarterly.

DNSSEC is now part of standard operations.

Next key ceremony XI

• The next ceremony will take place in Culpeper, VA on 2013 May 2-3.• Detailed schedule can be found at

http://dns.icann.org/ksk/upcoming-ceremonies/cer13/

• Watch the HD Live Stream at http://dns.icann.org/ksk/stream/

Stats

• 317 TLD’s in the root zone in total.

• 111 TLD’s are signed.

• 102 TLD’s have trust anchors published as DS records in the root zone.

• 2 TLD’s have trust anchors published in the ISC DLV Repository.

http://stats.research.icann.org/dns/tld_report/index.html