Signing the root with DNSSEC

Signing the root with
Anne-Marie Eklund Löwinder
Chief Information Security Officer
[email protected]
Twitter: amelsec
Thank’s to Fredrik Ljunggren, Kirei & Mehmet Akcin, ICANN
How did it all begin?
Walking down Memory Lane!
Paul Mockapetris
invents the DNS
and implements
the first server:
Formal IETF Internet Standard.
Two RFC's describes DNS: 1034
and 1035.
Steven Bellovin
describes cache
poisoning for the
first time, but the
report is held back
until 1995.
first version of the DNSSEC
standard is published.
RFC2535 is published, updating
The DNSSEC protocol seems to
be finally finished. BIND9 is
developed to be the first DNSSEC
capable implementation.
Sequential transaction ID:
Problems persisted.
Multiple name server
implementations used
sequential transaction ID’s,
trivial to guess. (March)
Experiments show that the
key handling in RFC2535 is
causing operational
problems that would make
deployment difficult, if not
Redesigning is initiated.
Multiple queries (November):
Problems persisted in multiple
An attacker could generate
several outstanding queries for
the same data. Enabled spoofing
through the birthday attack.
Brains are working on it…
Brains are working on it…
Brains are working on it…
The current RFC's are published:
RFC4033, RFC4034, RFC4035
Sweden (.SE) deploys DNSSEC.
.SE is the first TLD to adopt.
Others are *thinking* about
deploying DNSSEC…
Others are *thinking* about
deploying DNSSEC…
Predictable RNG (July):
Problems persisted, weaknesses in
the PRNG’s (pseudo-random
number generators) made guessing
through statistical analysis feasible.
Multiple implementations.
Yet another flaw in the DNS
protocol: The Kaminsky bug!
Targeting sibling names of a zone enabled
infinite number of retries for cache
The Domain Name System
desperately needs DNSSEC!
Mending and patching obviously
didn't do it…
Others *are* deploying DNSSEC.
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
The guiding principle behind
the design is that the result
must be trustworthy.
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
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
• 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
(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
Systrust audit performed annualy.
Trusted Community
Representatives (TCR)
• Have an active role in the management of the
• 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.
Recovery Key Share Holder
• 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
5-of-7 RKSH smartcards and an encrypted KSK
smartcard can reconstitute KSK in a new HSM.
Backup KSK encrypted on smartcard held by
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
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 – West Coast
• CO Backup
Christopher Griffiths, US
Fabian Arbogast, TZ
John Curran, US
Nicolas Antoniello, UY
Rudolph Daniel, UK
Sarmad Hussain, PK
Ólafur Guðmundsson, IS
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
• 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
• Watch the HD Live Stream at
• 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.

similar documents