1. Anne-Marie Eklund Löwinder Chief Information Security Officer amel@iis.se Twitter: amelsec http://www.iis.se Thank’s to Fredrik Ljunggren, Kirei & Mehmet Akcin, ICANN Signing the root with DNSSEC

2. How did it all begin? Walking down Memory Lane!

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

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

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

6. 1997 RFC2065 first version of the DNSSEC standard is published.

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

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

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

10. 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.

11. 2002 Brains are working on it…

12. 2003 Brains are working on it…

13. 2004 Brains are working on it…

14. 2005 Eureka! The current RFC's are published: RFC4033, RFC4034, RFC4035

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

16. 2006 Others are *thinking* about deploying DNSSEC…

17. 2007 Others are *thinking* about deploying DNSSEC…

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

19. 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.

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

21. 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.

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

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

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

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

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

27. Terramark Data Center, Culpeper, VA

28. Physical security

29. Physical Security

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

31. Physical Security Enforced Dual Occupancy. Separation of Duties. External Monitoring. Video Surveillance. Motion, Seismic other Sensors …and more.

32. 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.

33. 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).http://tools.ietf.org/html/rfc6841

34. 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.

35. 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.

36. 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/

37. 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.

38. 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)

39. I’ve got the key to the Internet!

40. 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

41. Key Signing Key (KSK) KSK is 2048-bit RSA. Rolled as required. RFC 5011 for automatic key rollovers. Signatures made using SHA-256.

42. 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.

43. Key Ceremonies Key Generation. Generation of new KSK. Processing of ZSK Signing Request (KSR). Signing ZSK for the next upcoming quarter. Quarterly.

44. DNSSEC is now part of standard operations.

45. 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/ http://dns.icann.org/ksk/upcoming- ceremonies/cer13/ Watch the HD Live Stream at http://dns.icann.org/ksk/stream/

46. 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