DNSSECKey Management
PolicyEdward Lewis
NeustarDNSSEC JP!
July 21, 2010ed.lewis@neustar.biz

1

Agenda• What is Key Management?
• Why and Where it ﬁts?
• Key Management in detail• Our experience in "dotUS" and "dotBIZ"

July 21, 2010ed.lewis@neustar.biz

2Key Management• I learned a lot by reading US NIST documents– I am not sure if the same exist in Japan• A reading list for Key Management & DNSSEC– hVp://csrc.nist.gov/publicaZons/PubsSPs.html– SP800‐57, also see SP800‐53, SP800‐81• Helpful informaZon on HSM devices– hVp://csrc.nist.gov/publicaZons/PubsFIPS.html– FIPS 140‐2
July 21, 2010ed.lewis@neustar.biz

3Why Manage Keys?
• DNSSEC uses keys to produce digital signatures• Keys are used in diﬀerent ways
• Keys have "lifeZmes" and cannot be
considered to be "forever"• There is a lot of debate on how long to use akey and how a key should be used
July 21, 2010ed.lewis@neustar.biz

4電子署名の概念
平文

鍵生成

署名生成

署名検証

公開鍵

平文

平文

秘密鍵

秘密鍵

公開鍵

電子署名

電子署名

ハッシュ関数

ハッシュ関数

ランダム番号ジェネレータ
July 21, 2010ed.lewis@neustar.biz

5The grey box• On the previous slide a gray box groups– 鍵生成– 署名生成– ランダム番号ジェネレータ
– ハッシュ関数• These funcZons may be in a sodware library(like OpenSSL) or may be in an Hardware
Security Module (HSM)
July 21, 2010ed.lewis@neustar.biz

6

3 ways data changes in DNSSEC• Zone ﬁle's data changes (same in DNS)
– New hosts/addresses/etc.

• Signatures expire (new in DNSSEC)– DNSSEC relies on expiraZon Zme for revocaZon– Signatures have to be "refreshed"• Key/cryptographic material changes (also new)
– Keys and algorithms don't last forever– Recovery from an aVack may require new keys
July 21, 2010ed.lewis@neustar.biz

7

DNSSEC Flow

HSM
署名生成

DNSゾーン
データベースDNSSEC
署名手順

DNSSECの署名の管理

鍵キャッシュ秘密鍵

DNSSECの鍵管理

公開鍵
ネーム
サーバ

July 21, 2010ed.lewis@neustar.biz

鍵生成

ランダム番号ジェネレータ
8

HSM &DNSSEC署名手順• HSM or sodware cryptographic library– Provides the "mathemaZc muscle" forcryptography– (non‐HSM: Openssl libraries)• DNSSEC署名手順 signs current data withcurrent keys
– Puts the cryptography into DNSSEC records, zones– Feeds the name server
July 21, 2010ed.lewis@neustar.biz

9When and How (to Sign) Policy• Decision of when to sign is governed by– DNSゾーンデータベース because data is changed– DNSSECの署名の管理 because signatures are
expiring (or wall‐clock alarm strikes)• Decision of what key to use is governed by– DNSSECの鍵管理 has to manage the current set
and changes to the next set of keys
July 21, 2010ed.lewis@neustar.biz

10Please Recycle• Regarding "when to sign"– GeneraZng new signatures before it is necessary
to do so is discouraged– Zone transfers become large and name servers sZll
are not good at juggling zone transfers and queries• If a zone is staZc, let signatures live long andrefresh them with short overlaps
July 21, 2010ed.lewis@neustar.biz

11

DNSゾーンデータベース• Changes to the zone contents will cause
DNSSEC signing to happen– User changes to the zone (new host)– DNSSECの鍵管理 delivers a new 公開鍵– (Not shown) NSEC3 parameter is changed• Policy– A zone must always have a complete set of freshsignatures. No excepZons!
July 21, 2010ed.lewis@neustar.biz12

DNSSECの署名の管理• DNSSEC signatures have expiraZon Zmes
– When a signature expires it must be refreshed– Usually this funcZon is built into other tools• Policy– Rule of thumb, refresh signature well before
expiraZon to give enough Zme to "recover" from afailure

July 21, 2010ed.lewis@neustar.biz13

DNSSECの鍵管理• Determines if the exisZng keys are "good" or if
there is a need to change• Key Management Policy– Following slides• Policy implementaZon– Requires new key pairs to be generated– Sends DNSゾーンデータベース new public keys
– Rotates keys into and out of service– Revokes keys
July 21, 2010ed.lewis@neustar.biz

14

Key Management Policy Aspects• Key roles– Use KSK/ZSK or not? Follow RFC 5011?

• Key algorithm (and hash) and size
– RSA SHA256? SHA1? SHA512? GOST?
– 1024 bits or 2048 bits?

• Key lifeZme– DuraZon of key "eﬀecZvity" period– Procedure and Zming of key change
July 21, 2010ed.lewis@neustar.biz

15

Key Roles• Choose KSK/ZSK or just one key?
– If the parent zone is fast and responsive, one keyis good
– But if the parent is slow, the KSK/ZSK approach isworth the management of the extra key• KSK/ZSK– Assumed by DNSSEC early adopters, not arequirement– See RFC 4641
July 21, 2010ed.lewis@neustar.biz

16KSK/ZSKParent Zone
子ゾーン.日本 DS 12345 8 2 A057C8553....
Child Zone...
子ゾーン.日本 DNSKEY 257 ... ; keyid = 12345
子ゾーン.日本 DNSKEY 256 ... ; keyid = 32123
子ゾーン.日本 RRSIG DNSKEY ... ; by 12345
The ZSK
July 21, 2010ed.lewis@neustar.biz

17Single Key DNSSEC• Managing 1 key is simpler than managing 2• But only if you have a "quick" relaZonshipwith your parent zone
– Need to change the DS record every Zme youchange the key signing the zone
– Or, if you never change keys...

• Since the invenZon of EPP, this is plausible– You can try it, but I sZll encourage KSK/ZSKJuly 21, 2010ed.lewis@neustar.biz18

Single Key "Chain"
Parent Zone
子ゾーン.日本 DS 12345 8 2 A057C8553....
Child Zone...
子ゾーン.日本 DNSKEY 257 ... ; keyid = 12345
子ゾーン.日本 RRSIG DNSKEY ... ; by 12345

The ZSK
July 21, 2010ed.lewis@neustar.biz

19

RFC 5011• Management of trust anchors– A new key has to be present for some Zme toverify it is indeed a new key– A revoked key is marked and signed for some Zme
to verify the key is removed• Intended for use where the parent zone is not
signed or won't hold DS records

July 21, 2010ed.lewis@neustar.biz20

Key Algorithm and Size
• DSA, RSA, RSA+NSEC3, GOST
– See hVp://www.iana.org/assignments/dns‐sec‐alg‐numbers/dns‐sec‐alg‐numbers.xhtml• Hash funcZon– SHA‐1 , SHA‐256 or something else?
– SHA‐1 is considered to be "old" but sZll in use• Size– Longer is harder to break, slower to use
July 21, 2010ed.lewis@neustar.biz

21

The Hash FuncZon• SHA 1– Published in 1995
– 160 bits
– Widespread, but gerng to be "breakable"• SHA 2 (or SHA 256 or SHA 512)
– Published in 2001
– 224/256 or 384/512 bits
– More bits, harder to "break"
July 21, 2010ed.lewis@neustar.biz

22Is longer beVer and slower?
• A longer key is thought to be– harder to "crack" so it is more secure– harder to process so it is less eﬃcient• What do cryptographers feel?
– DNSSEC is uses a subset of cryptographic funcZons– There isn't enough use of a key to crack it,provided it is strong enough (1024 bits)• Frankly, no one has enough experience yet
July 21, 2010ed.lewis@neustar.biz23

Key LifeZme• LifeZme, from creaZon to deleZon, comprises– Key eﬀecZvity period, the duraZon a key is usedcryptographically– Key DNSSEC lifeZme, the duraZons needed topublish and remove a key, DNS TTL plays a role
– RFC 5011 impacts Zming to allow detecZon of key
changes if there is no parent signing

July 21, 2010ed.lewis@neustar.biz24

Key eﬀecZvity period• There is some debate– DNSSEC developers thought that keys had to bechanged because of cryptographic properZes– Cryptographers have said (opinion) that keys will
be good "unZl broken" (which is true)– In operaZons, regular changes are good because• Broken keys may not be detected• Keys cannot be revoked (RFC5011 is a special case)• OperaZonal scripts need to be exercised
July 21, 2010ed.lewis@neustar.biz

25

TTL impacts• hVp://tools.iet.org/html/drad‐morris‐dnsop‐dnssec‐key‐Zming‐02• Assume a key is eﬀecZve for 3 months• What about DNS zone and cache propagaZon?
– A new key has to be pre‐published to avoid acache with a "new data signature and old keys."– An old key has to hand around unZl all of its
signatures are gone
July 21, 2010ed.lewis@neustar.biz

26

Cache Impact
Au Nt ShCa Nch Se

公開鍵#2Ca
公開鍵#1 c NShe

Au Nt Sh

公開鍵#1Ca N
公開鍵#1 hc Se

Ca Nch Se

公開鍵#2Ca N
公開鍵#2 c She

公開鍵#1

Ca N
公開鍵#1 hc S
e

公開鍵#2

Ca
公開鍵#2 c NShe

公開鍵#2

Ca N
公開鍵#2 hc S
e

0日 1日
2日 3日
Au Nt ShC
a Nch Se

公開鍵#2Ca
公開鍵#2 c NSheAu Nt Sh

公開鍵#2Ca N
公開鍵#1 hc Se

Ca Nch Se

July 21, 2010ed.lewis@neustar.biz

27

DNSSEC Basic DNSKEY cyclet=0t=1t=2t=3• t=0 DNSKEY is added to zone
• unZl t=1 Some caches will have the old set• t=1 All caches should have DNSKEY• unZl t=2 Private key can make RRSIG• t=2 private key reZred• unZl t=3 RRSIGs in Caches, DNSKEY needed• t=3 DNSKEY is removed from zone
July 21, 2010ed.lewis@neustar.biz28

BIND key management• In BIND 9.7 there is a new key mangement
feature– (P)ublish is t=0– (A)cZvate is t=1– (I)nacZvate is t=2– (D)elete is t=3

July 21, 2010ed.lewis@neustar.biz29

Experience in US and BIZ• US signed in December 2009, open for DS
records in June 2010
• BIZ began signing July 2010
• Both zones are using NSEC because there is no
reason to use NSEC3– Zones can be retrieved via FTP– We aren't concerned about size
July 21, 2010ed.lewis@neustar.biz30

My personal TLD survey• I have a script that asks for DNSKEY from thedelegaZons in the root and in ARPA
– Skewed by test zones in the root
– ARPA includes e164.ARPA and other signed zones• As of early July, 24 "real" TLDs are signed– I use this only for sanity checking, not reliable as ameasure of overall DNSSEC adopZon– You will see reference to "41" ‐ that includes testzones and ARPA zones
July 21, 2010ed.lewis@neustar.biz31

Key Roles• We use KSK/ZSK– Because our parent is slow (the root), noautomaZc update interface and no quick
turnaround– We plan to change keys frequently• Survey, 40 out of 41 use KSK/ZSK– But that isn't surprising as we all think alike• Single key use– Workable but in my opinion, not too scaleableJuly 21, 2010ed.lewis@neustar.biz32

Key Algorithm• No crypto system is imposed (by law) so wechoose what seems best
• From the 41 signed zones in the root plus
ARPA all use RSA– 9 zones use RSA‐SHA256, rest use RSA‐SHA1• RecommendaZon– Unless you must use an algorithm for legal
reasons, choose RSA‐SHA256• Don't start with RSA‐SHA1 (NSEC or NSEC3!)
July 21, 2010ed.lewis@neustar.biz33

Key Sizes• We have stuck to the common wisdom of a
KSK of 2048 and a ZSK of 1024 bits
• Survey "the most common set up"

July 21, 2010ed.lewis@neustar.biz34

Key LifeZme• Key eﬀecZvity– 1K bit ZSK ‐ 3 months– 2K bit KSK ‐ 1 year

• Our parameters– ZSK published as a emergency key for 3 months,
signs for 3 months– KSK is published for 1 year as the emergency and 1year as the acZve (DS at root)– TTL is 6 days
July 21, 2010ed.lewis@neustar.biz35

RFC 5011 support• We plan to support RFC 5011
– But in reality we could just rely on the root zone tohave the DS record– As a safety mechanism, we publish our key set on
a website, so RFC 5011 support is a good thing• No clear recommendaZon on RFC 5011
– Needed if parent is not signed– Probably not if signed
July 21, 2010ed.lewis@neustar.biz

36

QuesZons• QuesZons?

July 21, 2010ed.lewis@neustar.biz

37