Rolling the Root Zone DNSSEC Key Signing Key
0 likes4,007 views
The document discusses the impending change of the root zone DNSSEC Key Signing Key (KSK) by ICANN, emphasizing the necessity for network operators to prepare for potential impacts on DNSSEC validations. It covers the roles of various DNSSEC keys, the importance of maintaining trust anchors, and the technical details surrounding DNSSEC validation. There are specific dates and plans outlined for the KSK transition, highlighting the significance of proper preparation to avoid disruptions in DNS services.
Rolling the Root Zone DNSSEC Key Signing Key
- 1. | 1 Rolling the Root Zone DNSSEC Key Signing Key Edward Lewis | APNIC 42 | October 3. 2016 edward.lewis@icann.org
- 2. | 2| 2 Motivation for this talk β’ ICANN is about to change an important configuration parameter in DNSSEC β’ For a network operator, this may create a need for action β’ This discussion is meant to inform: Why this is happening, what is happening, and when β’ Highlighting: the availability of project plan documents
- 6. | 6| 6 What is DNSSEC Validation? β’ Validation includes the process of inspecting the digital signature and the data to verify the answer is the appropriate one β’ The signature and data need a public key, a chain of keys, and a trust anchor β’ Software tools today can do this when configured β’ Validation is more than a cryptographic check β’ Is the answer related to the question? β’ Is the answer "fresh", replayed, and so on?
- 7. | 7| 7 Why Bother? β’ Why bother? β’ The DNS protocol is gullible, easily fooled β’ Forged answers in DNS can result in misdirected traffic β’ Protect your DNS service, protect customers β’ Validation is "self-protection" β’ With DNSSEC as a base β’ Extensions to secure email transfer (stop spam) β’ Supplement to X.509 Certificate operations
- 8. | 8| 8 Roles of Keys in DNSSEC β’ DNSSEC has three kinds of records that, in some loose definition, hold cryptographic key data. The records exist because of the use of the data or "role"/"job" β’ KSK β Key Signing Key, produce signatures of keys β’ ZSK β Zone Signing Key, produces all other signatures β’ DS β Delegation Signer, a "pointer" to a key β’ This was supposed to simplify DNS operations!
- 11. | 11| 11 Over 1300 DNS - DNSSEC TLDs The Root .COM root ZSK root KSK .NET .NL.INFO .UK .BR .SE .δΈε½ com. DS .LK .ORG net. DS org. DS lk. DS uk. DS Over 1300 DS sets! +Over 500K in com...
- 13. | 13| 13 What is a Trust Anchor? β’ Besides being the "top" of any DNSSEC validation process? β’ A trust anchor is a key that an operator places full faith and trust into for the purposes of verifying responses β’ It could be implicitly trusted because it came with the software β’ It could be explicitly trusted via due diligence examination
- 14. | 14| 14 Is the Root Zone KSK the Trust Anchor? β’ Maybe β’ It's really up to you β’ By convention, there's a unique root zone, it has a KSK, for the global public Internet operated by ICANN β’ By default, DNSSEC validation tools come configured with that KSK as the trust anchor β’ But a user of the tools can add other trust anchors
- 16. | 16| 16 DNSSEC in the Root Zone β’ DNSSEC in the Root Zone is managed by: β’ ICANN, responsible for operating the root KSK β’ Verisign, responsible for operating the root ZSK β’ Operating the KSK β’ KSK lifecycle management, "sign the ZSK" β’ Operating the ZSK β’ ZSK lifecycle management, "sign the root zone" β’ Activities are coordinated but operated separately
- 17. | 17| 17 Current Root KSK β’ The current root KSK was created in 2010 β’ Stored in Hardware Security Modules in two Key Management Facilities β’ The operations surrounding the key is an entirely different talk
- 18. | 18| 18 β’ Via the DNS β’ As reliable as the data in unprotected DNS β’ (Works if you not subject to an "attack") β’ Via the Web β’ https://data.iana.org/root-anchors/root- anchors.xml β’ Secured by an X.509 certificate and signature β’ Via other means β’ Code β’ Presentations, t-shirts, friends β’ Always remember to check the legitimacy! Getting the Root KSK (Public portion only!)
- 19. | 19| 19 Changing the Root KSK β’ There is a plan in place to change the root KSK β’ For the first time β’ This plan is precedent setting β’ Because it involves an uncountable roster of participants and impacted parties β’ When ICANN changes the KSK on our end - β’ Anyone who (anonymously) relies on it has to change a configuration on their end β’ No one can list all those involved β unless something goes wrong
- 20. | 20| 20 Why (rock the boat)? β’ Good cryptographic hygiene β’ Secrets don't remain secret forever β’ Good operational hygiene β’ Have a plan, complete enough to execute β’ Exercise the plan under normal circumstances β’ Why not a private test? β’ The change of the KSK involves everyone doing DNSSEC validation on the Internet, service operators, software producers
- 21. | 21| 21 Bottom Line β’ Changing the root KSK will impact just about all DNSSEC validations β’ If the trust anchor is "misconfigured" (i.e., the wrong key) DNSSEC will reject legitimate responses β’ To anyone or any process relying on DNS, it will appear that the desired data is unavailable, website is unreachable, "the Internet is down" β’ There's a broader topic of trust anchor maintenance, but that is for another time
- 23. | 23| 23 The KSK Rollover Project and Network Operators β’ The project is meaningful to you if you are performing DNSSEC validation β’ Geoff Huston stats: steady 15% world wide β’ DNSSEC signing is not affected β’ If you are validating it's time to revisit configurations and processes β’ A root KSK roll hasn't happened before, it's new to all of us
- 24. | 24| 24 β’ The KSK Rollover Plan Documents β’ Available at: https://www.icann.org/kskroll 2017 KSK Rollover Operational Implementation Plan 2017 KSK Rollover Systems Test Plan 2017 KSK Rollover Monitoring Plan 2017 KSK Rollover External Test Plan 2017 KSK Rollover Back Out Plan β’ We encourage interested folks to given them a read
- 25. | 25| 25 Overview of Project Plans β’ Plans say - On October 11, 2017 a new KSK will go into use and the current KSK retired β’ On this day, if preparations haven't been made, trouble will ensue β’ Plans include β’ Retaining the current cryptography settings β’ Following Automated Updates of DNSSEC Trust Anchors β’ Fitting the roll into normal maintenance events β’ Testing and monitoring
- 26. | 26| 26 The Project's DNS Response Size Concerns β’ Significant DNS responses will grow to 1425 bytes during the project β’ Experimentation, especially in IPv6, suggests this might be a concern despite empirical evidence to the contrary β’ How to avoid potential problems β’ Where UDP is allowed to port 53, also allow TCP β’ Refrain from filtering DNS messages based on size
- 27. | 27| 27 IPv6 fragmentation and DNS β’ IPv6 fragmentation is done by the sender with intermediate nodes using ICMP to indicate a fragment as being "too big" β’ By the time the DNS sender gets the ICMP, DNS has forgotten what it had sent β’ From Geoff Huston experiments and analysis β’ http://www.potaroo.net/ispcol/2016-05/v6frags.html β’ TCP over IPv6 use an MTU of 1,280 bytes β’ UDP has marginal advantages with using larger MTU, "but"
- 28. | 28| 28 Dates to Watch β’ September 19, 2017 β’ The root zone DNSKEY set will increase to 1414 bytes for 20 days, prior to that date 1139 bytes has been the high water mark β’ October 11, 2017 β’ On this date the root zone DNSKEY set will be signed only by the new KSK β’ January 11, 2018 β’ The root zone DNSKEY set will increase to 1425 bytes for 20 days
- 29. | 29| 29 Trust Anchor Management β’ How do you trust and configure? β’ Are trust anchors subject to configuration control? β’ Rely on embedded data in software? β’ Are DNSSEC validation failures monitored? β’ Automated Updates of DNSSEC Trust Anchors β’ Most direct, reliable means for getting the key β’ Negative Trust Anchor management β RFC 7646 β’ Protects against errors made by others
- 30. | 30| 30 Tools & Testbeds β’ We are working with DNS software and tool developers and distributors β’ Management/troubleshooting aids β’ Updates of bundled keys β’ Testbeds for Code Developers β’ Automated updates: http://keyroll.systems/ β’ Root zone model: https://www.toot-servers.net/ β’ Testbeds for Service Operators β’ I.e., using "off-the-shelf" parameters β’ Planned for end-of-2016
- 31. | 31| 31 β’ Join the ksk-rollover@icann.org mailing list: β’ https://mm.icann.org/listinfo/ksk-rollover β’ Follow on Twitter β’ @ICANN β’ Hashtag: #KeyRoll β’ Visit the web page: β’ https://www.icann.org/kskroll For More Information
- 32. | 32| 32 Reach me at: Email: ksk-rollover@icann.org Website: icann.org/kskroll Thank You and Questions gplus.to/icann weibo.com/ICANNorg flickr.com/photos/icann slideshare.net/icannpresentations twitter.com/icann facebook.com/icannorg linkedin.com/company/icann youtube.com/user/icannnews Engage with ICANN