1. Rolling the Root Zone DNSSEC Key Signing Key
Alexandra Kulikova| EE DNS Forum| 1 December, 2016

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

3. Trust Anchors & Root KSK1 2 3
Trust Anchors & Root KSK
Root Zone
DNSSEC
KSK Roll Project

4. DNS for Those Who Don’t Like Protocols
What is the IPv6 address
for
is 2001:db8::

5. DNS for Those Who Don’t Like Protocols
What is the IPv6 address
for
is 2001:db8::
Digital signature by example.com.

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 the 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. Why Bother? Why bother? Validation is “self-protection” for clients
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” for clients
With DNSSEC as a base
Extensions to secure transfer (stop spam)
Supplement to PKIX certificate operations

8. Roles of Keys in DNSSEC
DNSSEC has two kinds of cryptographic keys. 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
Both types of keys are kept in DNSKEY resource records

9. Crypto-checking a Signature
is 2001:db8:: ✔ ?
Digital signature by example.com. OR ✖
example.com. ZSK

10. Trusting a Key
root KSK
The Root
root ZSK
com. DS
com. KSK
.COM
com. ZSK
example.com. DS
example
example.com. KSK
example.com. ZSK

11. Over 1300 DNS - DNSSEC TLDs
root KSK
The Root
root ZSK
com. DS
net. DS
.COM
.BR
.UK
org. DS
lk. DS
.SE
.中国
.ORG
uk. DS
.LK
Over 1300 DS sets!
.NET
.NL
.INFO
+Over 500K in com...

12. Anchor of the Chain of Trust
The Root
root KSK
root ZSK
com. DS
.COM
com. KSK
com. ZSK
example.com. DS
example
example.com. KSK
example.com. ZSK

13. What is a Trust Anchor?
It is the “top” of any DNSSEC validation process
A trust anchor is a key into which an operator places full faith and trust for the purposes of verifying responses
It might be implicitly trusted because it came with the software
It might be explicitly trusted because of due diligence examination by the operator

14. Trust Anchors & Root KSK1 2 3
Trust Anchors & Root KSK
Root Zone
DNSSEC
KSK Roll Project

15. DNSSEC in the Root Zone
DNSSEC in the root zone is managed by ICANN and Verisign
ICANN, responsible for operating the root KSK
KSK lifecycle management, “sign the ZSK”
Verisign, responsible for operating the root ZSK
ZSK lifecycle management, “sign the root zone”
These activities are coordinated but are operated separately

16. Current Root KSK The current root KSK was created in 2010
Stored in hardware security modules (HSMs)
Two key management facilities (KMFs) have the same data as redundant backups
(The operation of these is an entirely different talk)

17. Getting and Validating the Root KSK
The root KSK comes in the DNS
...but is only as reliable as the data in unprotected DNS
Get the trust anchor validation from IANA directly
Secured by a PKIX certificate and signature
Trust anchor validation may also come by other means
Might come in the source code of your validating software

18. Changing the Root KSK The root KSK is changing for the first time
This plan is precedent-setting because it involves an uncountable roster of participants and impacted parties
When the KSK changes, anyone who relies on it has to change a configuration on their end
Although their software might make this happen automatically
We don’t know who is relying on it because they don’t have to register anywhere

19. Why make this change? Good cryptographic hygiene
Secrets may not remain secret forever
Good operational hygiene
Have a plan that is complete enough to execute
Exercise the plan under normal circumstances
Why not first do a private test?
The change of the KSK involves everyone doing DNSSEC validation on the Internet, service operators, software producers

20. 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”

21. Trust Anchors & Root KSK1 2 3
Trust Anchors & Root KSK
Root Zone
DNSSEC
KSK Roll Project

22. Overview of Project Plans
Steps are happening now
The new KSK was created on October 27, 2016
If the plan stays on track, on October 11, 2017 a new KSK will go into use and the current KSK retired
If someone is validating using manual configuration, they need to have the new trust anchor in place by that date
Plans include
Following Automated Updates of DNSSEC Trust Anchors
Fitting the roll into normal maintenance events
Testing and monitoring

23. The KSK Rollover Plan Documents
Available at:
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

24. Operational Implementation Plan Dates
Plans publicly available from July 22, 2016
Key signing ceremonies
Q ceremony (October 27): generate KSK-2017
Q ceremony (February): KSK-2017 operationally ready
DNS changes
KSK-2017 added to root zone on July 11, 2017 (with KSK-2010 still there)
KSK-2017 signs DNSKEY RRset (instead of KSK-2010) beginning October 11, 2017
KSK-2010 revoked on January 11, 2018 but is still in the root zone

25. DNS Response Size Concerns
Specific 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
Do not filter DNS messages based on size

26. 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: 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

27. Trust Anchor Management
Automated updates of DNSSEC trust anchors
Most direct, reliable means for getting the key
Often called “RFC 5011 updates”
Manual configuration
Are your trust anchors subject to configuration control?
Do you know how your software is configured?
Are DNSSEC validation failures monitored?

28. Tools & Testbeds
We are working with DNS software and tool developers and distributors
Management/troubleshooting aids
Updates of bundled keys
Testbeds for Service Operators
Can test your setup to see if automatic updates for new trust anchors work
Planned for end-of-2016

29. For More Information Join the ksk-rollover@icann.org mailing list:
Follow on Twitter
@ICANN
Hashtag: #KeyRoll
Visit the web page:
Note: inserted graphics

30. Engage with ICANN Thank You and Questions Reach me at:
Website: icann.org/kskroll
twitter.com/icann
gplus.to/icann
facebook.com/icannorg
weibo.com/ICANNorg
You can adjust the /web address to whichever or web address is best suited to your presentation. This should be your final slide.
linkedin.com/company/icann
flickr.com/photos/icann
youtube.com/user/icannnews
slideshare.net/icannpresentations