dnssec keys and ksk rollover - os3 · ©2016 stichting nlnet labs dnssec keys and ksk rollover...

http://www.nlnetlabs.nl/©2016 Stichting NLnet Labs

DNSSEC Keys and KSK Rollover

Jaap Akkerhuis

http://www.nlnetlabs.nl


Overview• Some history

• Key Generation in Practice

• KSK Roll Plans



DNSSEC Recap• Digital signatures are added to responses

by authoritative servers for a zone

• Validating resolver can use signature to verify that response is not tampered with

• Trust anchor is the key used to sign the DNS root

• Signature validation creates a chain of overlapping signatures from trust anchor to signature of response



DNSSEC Validation

.nlnetlabs.nl.

Arecordwww.nlnetlabs.nl.+signature .nl.

.

validatingresolver

DNSKEYrecord.nlnetlabs.nl.+signature

DSrecord.nlnetlabs.nl.+signatureDNSKEYrecord.nl.+signature

DSrecord.nl.+signatureDNSKEYrecord.+signature

localrootkey(preloaded)

1

2

3

4

5



History• Personal story

• Personal archives are lost

• Incomplete

• Not even tried to be



Early beginnings• Early 80’s CWI (MC) got a VAX (#37)

• How to connect to the 11/45?

• Ethernet, no software

• UUCP to the rescue

• Store and forward networking with remote execution

• Serial lines



Connecting stuff• Connected Europe by UUCP

• X.25, Datanet 1 etc,

• (Start of the ISO wars)

• Got another VAX (750) in the process

• Started BSD Unix testing (4.1a)

• Had an TCP/IP stack

• Had Bind 4.8 or so



EUnet born• Started with mcvax (also McVAX)

• Still no routing to “The Internet”

• 1988 or so

• ~ 1989 Cache spoofing discovered

• 1993 Steven Bellovin, Bell Labs

• Went public in 1995 (or so)



DNSSEC• 1st version 1997

• RFC 2065

• Final RFC 2535 (1999)

• Didn't got much traction

• But TSIG actually did



DNSSEC and me• Since the ~1998 Ripe meeting

• Lot’s of workshops (RFC 3130)

• Large scale testing

• Various versions & refinements

• New rewrite RFC 4033 & friends (2005)

• KSK, ZSK, DS, NSEC got finalised



DNSSEC and me• Since the ~1998 Ripe meeting

• Crypto was seen as the main problem

• ICANN 21 Yokohama

• Showed how to sign a “big zone”

• Solution:

• Sound engineering and sysadmin



DNSSEC and me• SIDN with nlnetlabs & large scale testing

• KSK & ZSK was born

• Scaling studies

• Registry operations



Anti DNSSEC Voices

• Scaling problems

• Cost a lot, but no business case

• Opt-out

• Privacy

• Zone walking

• NSEC3

• Just for Geeks



Pro DNSSEC voices

• Just hardening doesn’t fix basic flaws

• It is infrastructure

• Builds a substrate to enable other applications

• Yeah, it is geeky



Kaminsky 2008• Accelerated the attack

• From weeks to minutes

• Another round of hardening

• very hush hush

• Started a slew of (new) exploits



Root signed 2010• KSK is for ICANN

• ZSK by Verisign

• First secured TLD: SE

• NL lost out



Snowdon Etc.• Accelareted DNSSEC acceptance

• Lot’s of privacy related apps builds on it

• Dane etc.

• CA Cert lost trust

• Raise to the bottom

• Diginotar Hack



The Key GenerationCeremony



Actors• ICANN

• ???

• PTI (IANA)

• ???

• TCR

• ???



Actors• ICANN

• Internet Corporation for Assigned Names and Numbers

• PTI (IANA)

• ???

• TCR

• ???



Actors• ICANN


• PTI (IANA)

• Public Technical Identifiers (Internet Assigned Numbers Authority

• TCR

• ???



Actors• ICANN


• PTI (IANA)

• Public Technical Identifiers (Inernet Assigned Numbers Authority

• TCR

• Trusted Community Representatives



What?• Root Zone Practice statement

• KSK ceremony Materials

• Audited

• Open to the Public (Live Video)

• www.iana.org/domains/root


http://www.iana.org/domains/root


Where?

Culpepper, VA



El Segunda, CA



The Ceremonyhttps://youtu.be/fUJM9tTvCG4


https://youtu.be/fUJM9tTvCG4


Why roll the KSK?• Good Cryptographic hygiene

• Secrets don't stay secret forever

• Good operational hygiene

• Have a plan, complete enough to execute

• Exercise the plan under normal circumstances



Roll the KSK now?• Promised to do so in 2010*

• “Each RZ KSK will be scheduled to be rolled over through a key ceremony as required, or after 5 years of operation.”

* https://www.iana.org/dnssec/icann-dps.txt Section 6.5



Effect of KSK roll• Impacts all DNSSEC validating resolvers

(worldwide 15%)

• with misconfigured keys:

the Internet is DOWN



Planning• Plans 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

Do give these a read


https://www.icann.org/kskroll


New Key created• Culpepper VA, Oct 27, 2016

• Installed at El Secundo CA, 2 Feb 2017



Important dates• July 11, 2017: Publication of new KSK in

DNS

• October 11, 2017: New KSK begins to sign the root zone key set (the actual rollover event)

• January 11, 2018: Revocation of old KSK



Steps to take

I C A N N | 2017 KSK ROLLOVER OPERATIONAL IMPLEMENTATION PLAN | JULY 2016 | 5

For operators who implement Automated Updates of DNS Security Trust Anchors (RFC 5011) for the root zone, the rollover process will involve the three phases D, E and F. KSK-2017 is published in the root zone in phase D and begins its use for signing in phase E. KSK-2010 will stop being used in phase E and is then revoked in phase F. For operators who manage trust anchors out of band, the root zone trust anchors file is needed. The process for obtaining and authenticating this file is out of scope of this document. The trust anchors file will be updated after KSK-2017 is successfully replicated and when KSK-2010 is revoked. Changes to the keyset in the root zone and the trust anchors might lead to complications. Software may not be able to cope with the changes in the trust anchors file or the changed keyset in the root zone, while networks might not be able to handle an increased DNS response size. If these complications are widespread and severe, the Root Zone Management Partners may decide that these changes need to be undone to bring the system back to a stable state. This is referred to as a back out scenario.

ZSK-q1ZSK-q1

ZSK-…post-publish

Slot 9Slot 1Slot 9Slot 2…8Slot 1

ZSK-q3pre-publish

ZSK-q2

ZSK-…pre-publish

ZSK-q3ZSK-q3

ZSK-q2post-publish

KSK-2010publish+sign


KSK-2017publish


Slot 2…8

ZSK-q2


ZSK-q2pre-publish

ZSK-q1

Slot 1Slot 9

ZSK-q2

ZSK-q1post-publish


KSK-2017publish



Phase D – Publication Phase E – Rollover Phase F – Revocation

Slot 2…8

ZSK-q3


KSK-2010revoke+sign

Delayed revocation of KSK-2010

Second packet size increase

First packet size increase Rollover

Phase CFirst SKR

Phase BReplication

Phase AGeneration

First SKRwith new KSK

signed

New KSK created in 1st

KMF

New KSK replicated to

2nd KMF

Slot 1…9Slot 1…9Slot 1…9


KSK-2017publish

KSK-2010publish

KSK-2010publish

KSK-2010publish

2017 Q3 2017 Q4 2018 Q12017 Q22017 Q12016 Q4



Operator actions• If validator RFC 5011 compliant:

• Monitor as usual

• else manual intervention:

• Add new anchors to configuration when available

• Delete old anchor when revoked

• Did I mention to monitor your DNS?



Possible Hiccups• If 5011 protocol fails

• 5011 is a paradigm change:

• Changes configuration automatically

• Packet size prevents 5011 to work properly

• Human errors



Design team Report*

• Impact on Root zone management

• Operational reality

• Cryptography Considerations

• Change of key size, algorithm etc.

• Packet size implications

* https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf


https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf


Crypto Change?• While at it, chance algorithm

• Elliptic Curve Crypto is way more efficient

• Less implementations available

• HSM didn't support it …

• Don’t change multiple engines mid-flight



RFC 5011• Automated Updates of DNS Security

(DNSSEC) Trust Anchors

• Describes various states of trust anchors

• Start, AddPend, Valid, Missing, Revoked, Removed

• Describes phase changes

• Hold-down timers



Packet Size• DNS uses UDP 512 sizes

• Fall back to TCP

• ENDS(0) support

• DNSSEC needs that anyway

• IPv6 Fragmentation model differs from IPv4



(UDP) Fragmentation

• IPv4: In the network

• IPv6: At the end (in the app)

• Guarantees 1280b non-fragmented (eq. 1232b payload)

• Lots of ISPs ignore fragments

• (Ziggo, google etc.)



Tresholds

Size Threshold

512 octets Minimum DNS payload size that must be supported by DNS

1,232 octets Largest DNS payload size of an unfragmentable IPv6 DNS UDP packet

1,452 octets Largest DNS payload size of an unfragmented Ethernet IPv6 DNS UDP packet

1,472 octets Largest DNS payload size of an unfragmented Ethernet IPv4 DNS UDP packet



Time DNSKEY During Roll RRSIG During Roll DNSKEY Response Size During Roll

DNSKEY Response Size During Non-Roll

Q1 slot 1 1⋅ KSK + 2⋅ ZSK 1⋅ KSK 883 octets 883 octets

Q1 slots 2 to 8 2⋅ KSK + 1⋅ ZSK 1⋅ KSK 1,011 octets 736 octets

Q1 slot 9 2⋅ KSK + 2⋅ ZSK 1⋅ KSK 1,158 octets 883 octets


Q2 slots 2 to 8 1⋅ KSK + 1⋅ ZSK 1⋅ KSK 736 octets 736 octets



Q3 slots to 8 2⋅ KSK + 1⋅ ZSK 2⋅ KSK 1,297 octets 736 octets

Q3 slot 9 1⋅ KSK + 2⋅ ZSK 1⋅ KSK

Table 2. Packet Sizes During Rollover

Note: ZSK 1024 bits



What to do?• Ignore the IPv6 standard

• Up to 1452 is fine experience learns

• Afilias has violated thresholds for years; nobody noticed



Final remarks• DNSSEC improves the Infrastructure

• Solid Engineering, geen rocket science

• Proper planning with back-out for roll-over

• Communication with multiple stakeholder

• Monitoring of operation

• Transparant Process planning in best internet tradition


Questions



dnssec keys and ksk rollover - os3 · ©2016 stichting nlnet labs dnssec keys and ksk rollover...

Documents