Transcript Signing the root with DNSSEC

Signing the root with
DNSSEC
Anne-Marie Eklund Löwinder
Chief Information Security Officer
[email protected]
Twitter: amelsec
http://www.iis.se
Thank’s to Fredrik Ljunggren, Kirei & Mehmet Akcin, ICANN
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
RFC2065
first 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 used
sequential 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 multiple
implementations.
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 enabled
infinite 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
•
•
•
•
•
•
•
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
• 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/upcomingceremonies/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