1 / 47

Signing the root with DNSSEC

Signing the root with DNSSEC. 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. How did it all begin ? Walking down Memory Lane!. 1983 .

aquarius
Download Presentation

Signing the root with DNSSEC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Signing the root with DNSSEC 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

  2. Howdid it all begin?WalkingdownMemory Lane!

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

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

  5. 1990 Steven Bellovindescribes 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 capableimplementation.

  8. 1999 Sequential transaction ID: Problems persisted. Multiple name server implementationsused 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. Redesigningis 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) deploysDNSSEC. .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-randomnumber generators) madeguessingthroughstatisticalanalysisfeasible. Multiple implementations.

  19. 2008 Yet another flaw in the DNS protocol: The Kaminskybug! Targeting sibling names of a zone enabled infinite number of retries for cache poisoning.

  20. 2009 The DomainName System desperatelyneedsDNSSEC! Mending and patchingobviouslydidn'tdoit… Others *are* deploying DNSSEC.

  21. 2010 The Root is signedsince July15, 2010! . IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 DNSSEC in the root ties it all together and is an enablerfor so muchmore.

  22. Approach to DNSSEC in the rootzone and protection of the KSK

  23. Design The guidingprinciplebehind the design is that the result must be trustworthy.

  24. Audited Processes and proceduresshould be auditedagainstindustry standards e.g. ISO/IEC 27002:2005

  25. High security Root system shouldmeet all NIST SP 800-53 technicalsecuritycontrolsrequired by a HIGH IMPACT system.

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

  27. Terramark Data Center, Culpeper, VA

  28. Physicalsecurity

  29. Physical Security

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

  31. Physical Security • Enforced Dual Occupancy. • Separation of Duties. • ExternalMonitoring. • Video Surveillance. • Motion, Seismicother Sensors • …and more.

  32. ICANN staffrolesrelated 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 certificatepracticestatement (CPS) from an X.509 certification authority (CA). • Compliant with http://tools.ietf.org/html/rfc6841 (as a number of otherTLD’s are).

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

  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 ShareHolder (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. Annualinventory.

  38. Community Representatives • CO – East Coast • Alain Aina, BJ • Anne-Marie Eklund Löwinder, SE • FredericoNeves, BR • GaurabUpadhaya, NP • Olaf Kolkman, NL • Robert Seastrom, US • Vinton Cerf, US • CO – West Coast • Andy Linton, NZ • Carlos Martinez, UY • DmitryBurkov, RU • Edward Lewis, US • João Luis Silva Damas, PT • Masato Minda, JP • SubramanianMoonesamy, MU • CO Backup • Christopher Griffiths, US • Fabian Arbogast, TZ • John Curran, US • Nicolas Antoniello, UY • Rudolph Daniel, UK • Sarmad Hussain, PK • ÓlafurGuðmundsson, IS • RKSH • BevilWooding, TT • Dan Kaminsky, US • Jiankang Yao, CN • MoussaGuebre, BF • Norm Ritchie, CA • OndřejSurý, 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. • Signaturesmadeusing SHA-256.

  42. Zone Signing Key (ZSK) • ZSK is 1024-bit RSA. • Rolled once a quarter (four times per year). • Zone signed with NSEC. • Signaturesmadeusing 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/ • 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

More Related