Testing Rolling Roots
0 likes996 views
The document discusses the impending roll of the DNS root zone key signing key (KSK) and its implications, particularly for DNSSEC-validating resolvers. Concerns are raised about the ability of these resolvers to adopt the new KSK, especially those that do not support RFC5011 procedures, which may result in service disruptions. Various tests and observations regarding key roll impacts and resolver behaviors are highlighted, noting the importance of understanding user impacts and technical challenges during the transition.
Testing Rolling Roots
- 2. Use of DNSSEC in Today’s Internet
- 3. Use of DNSSEC in SE Asia
- 4. Use of DNSSEC in SE Asia 1 in 6 users in this region have their DNS queries resolved by DNSSEC-validating reslovers
- 5. Why is this relevant?
- 6. Because… the root zone managers are preparing to roll the DNS Root Zone Key Signing Key (and this may break your DNS service!) 6
- 10. ZSK? – Zone Signing Key – Used to generate the digital signature RRSIG records in the root zone – The ZSK is rolled regularly every quarter – The DNSKEY record for the ZSK is signed by the KSK
- 11. KSK? • The Root Zone Key Signing Key signs the DNSKEY RR set of the root zone – The Zone Signing Key (ZSK) signs the individual root zone entries • The KSK Public Key is used as the DNSSEC Validation trust anchor – It is copied everywhere as “configuration data” – Most of the time the KSK is kept offline in highly secure facilities
- 12. The Eastern KSK Repository
- 13. The Western KSK Repository El Segundo, California *
- 14. The Ultra Secret Third KSK Repository in Amsterdam KSK spotting by George Michaelson
- 15. The Uruguay Mobile KSK KSK spotting by George Michaelson
- 16. The Cast of Actors • Root Zone Management Partners: – Internet Corporation for Assigned Names and Numbers (ICANN) – National Telecommunications and Information Administration, US Department of Commerce (NTIA) – Verisign • External Design Team for KSK Roll
- 17. Approach • ICANN Public Consultation – 2012 • Detailed Engineering Study - 2013 • SSAC Study (SAC-063) - 2013 • KSK Roll Design Team - 2015
- 18. 2015 Design Team Milestones • January – June: Study, discuss, measure, ponder, discuss some more • August – Present a draft report for ICANN Public Comment https://www.icann.org/public-comments/root-ksk-2015-08-06-en (comment close 15th September 2015) • September – Prepare final report • Pass to the Root Zone Management Partners who then will develop an operational plan and execute
- 19. Rolling the KSK? • All DNS resolvers that perform validation of DNS responses use a local copy of the KSK • They will need to load a new KSK public key and replace the existing trust anchor with this new value at the appropriate time • This key roll could have a public impact, particularly if DNSSEC-validating resolvers do not load the new KSK
- 20. Easy, Right? • Publish a new KSK and include it in DNSKEY responses • Use the new KSK to sign the ZSK, as well as the old KSK signature – Resolvers use old-signs-over-new to pick up the new KSK, validate it using the old KSK, and replace the local trust anchor material with the new KSK • Withdraw the old signature signed via the old KSK • Revoke the old KSK
- 22. The RFC5011 Approach The point of no return The critical switch Pre-load
- 23. Just Like Last Time?
- 24. But that was then… And this is now: – Resolvers are now not so aggressive in searching for alternate validation paths when validation fails (as long as resolvers keep their code up to date, which everyone does – right?) – And now we all support RFC5011 key roll processes – And everyone can cope with large DNS responses So all this will go without a hitch Nobody will even notice the KSK roll at the root Truly ruly!
- 25. But that was then… And this is now: – Resolvers are now not so aggressive in searching for alternate validation paths when validation fails (as long as resolvers keep their code up to date, which everyone does – right?) – And now we all support RFC5011 key roll processes – And everyone can cope with large DNS responses So all this will go without a hitch Nobody will even notice the KSK roll at the root Truly Ruly! Not!
- 26. What we all should be concerned about… That resolvers who validate DNS responses will fail to pick up the new DNS root key automatically – i.e. they do not have code that follows RFC5011 procedures for the introduction of a new KSK The resolvers will be unable to receive the larger DNS responses that will occur during the dual signature phase of the rollover
- 27. Technical Concerns • Some DNSSEC validating resolvers do not support RFC5011 – How many resolvers may be affected in this way? – How many users may be affected? – What will the resolvers do when validation fails? • Will they perform lookup ‘thrashing’ – What will users do when resolvers return SERVFAIL? • How many users will redirect their query to a non-validating resolver
- 28. Technical Concerns • Some DNSSEC validating resolvers do not support RFC5011 – How many resolvers may be affected in this way? – How many users may be affected? – What will the resolvers do when validation fails? • Will they perform lookup ‘thrashing’ – What will users do when resolvers return SERVFAIL? • How many users will redirect their query to a non-validating resolver Really hard to test this in the wild with heading down the path of fake root zones And because of the RFC5011 30 day holddown then its not a simple “point your resolver here” kind of test
- 30. We’ve been testing large responses in the DNS • We are interested in sending DNSSEC-aware DNS resolvers a response that is much the same size as that being contemplated in a KSK key roll • And seeing whether they got the response
- 31. The Test • We are interested in resolvers who are DNSSEC aware (queries that contain the EDNS0 option with DNSSEC OK flag set on) • We would like to test larger responses: – 1,440 octets of DNS payload • We would like to test a couple of crypto protocols – RSA – ECDSA
- 32. EDNS(0) DNSSEC OK Set 76,456,053 queries 63,352,607 queries with EDNS(0) and DNSSEC OK set = 83% of queries 777,371 resolvers 649,304 resolvers with EDNS(0) and DNSSEC OK set = 84% of resolvers
- 33. EDNS(0) UDP Buffer sizes
- 34. EDNS(0) UDP Buffer sizes
- 35. EDNS(0) UDP Buffer sizes Around the 1425 octet response size we will see UDP response truncation rates of around 5.5%
- 36. Small vs Large 1,440 Octets Payload Experiments: 6,542,993 Web Fetch: 5,880,921 DS Fetch: 181,610 Timeout: 480,415 DNS Fail: 47 1,770 Octets Payload Experiments: 6,566,645 Web Fetch: 5,992,617 DS Fetch: 167,119 Timeout: 401,831 DNS Fail: 5,078
- 37. ECDSA vs RSA The spec says that when a resolver encounters a zone signed only with algorithms that are not supported by the resolver then it will treat the zone as unsigned and not proceed with validation Most resolvers determine the zone’s signing algorithms from the DS record What happens when we compare a 1,440 octet response signed by RSA and a 1,440 octet response signed by ECDSA?
- 38. 1,440 octet ECDSA-signed Responses 9,137,436 tests 7,766,572 retrieved the 1x1 blot 2,644,564 queried for the DS record 860,163 queried for the DS record (but no blot) 505,045 timed out (but no blot!) 5,656 appeared to fail the DNS
- 39. 1,440 octet ECDSA-signed Responses 9,137,436 tests 7,766,572 retrieved the 1x1 blot 2,644,564 queried for the DS record 860,163 queried for the DS record (but no blot) 505,045 timed out (but no blot!) 5,656 appeared to fail the DNS This is larger than RSA failure rates, but is still a small proportion of users affected. Some resolvers appear to have problems when presented with an unknown crypto protocol.
- 40. IPv4 vs IPv6 Do resolvers prefer IPv4 over IPv6? Total Queries: 47,826,735 Queries over V6: 394,816 Number of Resolvers: 109,725 Number of Resolvers using IPv6 for queries: 2,849
- 41. IPv4 vs IPv6 Do resolvers prefer IPv4 over IPv6? Total Queries: 47,826,735 Queries over V6: 394,816 Number of Resolvers: 109,725 Number of Resolvers using IPv6 for queries: 2,849 In a Dual Stack environment 1% of queries and 3% of resolvers use IPv6. What if the server was IPv6 only?
- 42. Some Observations - 1 There is a LOT of DNSSEC validation out there – 87% of all queries have DNSSEC-OK set – 30% of all DNSSEC-OK queries attempt to validate the response – 25% of end users are using DNS resolvers that will validate what they are told – 12% of end users don’t believe bad validation news and turn to other non-validating resolvers when validation fails.
- 43. Some Observations - 2 There is very little V6 being used out there – 1% of queries use IPv6 as the transport protocol when given a dual stack name server It seems that when given a choice: Browsers prefer IPv6 Resolvers prefer IPv4
- 44. Some Observations - 3 ECDSA is viable – sort of – 1 in 5 clients who use resolvers that validate RSA-signed responses are unable to validate the same response when signed using ECDSA – But they fail to “unsigned” rather than “invalid” so it’s a (sort of) safe fail
- 45. Some Observations - 4 The larger DNS responses will probably work – The “fall back to TCP” will rise to 6% of queries when the response size get to around 1,350 octets – And the DNS failure rate appears to rise by around 1 - 2 % – BUT .org currently runs at 1,650 octets and nobody is screaming failure – So it will probably work
- 46. Some Observations - 5 We can’t measure automated key take up – We can’t see how many resolvers fail to use RFC5011 notices to pick up the new KSK as a Truct Anchor in advance – We will only see it via failure on key roll
- 47. Where are we? • A key roll of the Root Zone KSK will cause some resolvers to fail: – Resolvers who do not pick up the new key in the manner described by RFC5011 – Resolvers who cannot receive a DNS response of ~1,300 octets • Many users who use these failing resolvers will just switch over to use a non-validating resolver • A small pool of users will be affected with no DNS
- 48. Now? Public comment: draft report for ICANN Public Comment https://www.icann.org/public-comments/root-ksk-2015-08-06-en Comments close 15th September 2015 Please read & comment
- 49. Questions?
- 50. Comments - 1 Why Now? What is the imperative to roll the key now? Could we use more time to improve preparedness for this roll? For example, could we use further time to introduce some explicit EDNS(0) signalling options in resolvers to expose RFC5011 capability? 50
- 51. Comments - 2 Measuring and Testing? What measurements are planned to be undertaking during the key roll process? What are the threshold metrics for proceeding to the next phase? What is the threshold metric to proceed with the revocation of the old KSK? 51
- 52. Comments - 3 Algorithm Change The report’s language around the potential for algorithm change is unclear. There appears to be a strong bias to retention of RSA as the KSK algorithm, despite evidence that ECDSA is both shorter and potentially faster to compute. Whilst the report argues for a reduced risk of large packets, it doesn’t clearly explain why larger RSA-based DNS response payloads would be preferable to smaller ECDSA DNS response payloads. 52
- 53. Comments - 4 Scheduling The report notes as a constraint that a key roll must be aligned with existing Quarter and 10-day periods used in existing processes. This has the potential consequence of scheduling the critical change in the root zone on a weekend, or on a major public holiday. Why? 53
- 54. Comments - 5 Testing for RFC5011 The report notes that there is no easy way to test is a resolver has picked up the new KSK via 5011 signalling (or otherwise)? Has the team working on this explored the use of sentinel zones signed by the new KSK? For example it could be envisaged that the roll process could use the incoming KSK to sign some sentinel record in the root zone allowing measurement of the extent to which resolvers are able to use the KSK as a trust anchor to validate the sentinel record. It would be helpful to understand why such potentially measurable actions are not viable options in this particular context. 54
- 55. Comments - 6 Serialization The report assumes a single new KSK. What are the issues of introducing 2 or even 3 new KSKs at this point? 55
- 56. Comments - 7 All together all at once? Why do all root zones flip to use the new KSK all at the same time? Why is there not a period of dual sigs over the root ZSK? Why not allow each root server to switch from old to old+new to new using a staggered timetable? There may be perfectly sound reasons why all together all at once is a better option than staggered introduction, but report does not appear to provide any such reasons. 56