Impact of Rolling the Root KSK. Ed Lewis NetNod October 2015

Transcription

1 Impact of Rolling the Root KSK Ed Lewis NetNod October 2015

2 Agenda Background on DNS, DNSSEC ICANN as the KSK maintainer Valida=on of DNSSEC Impact of a Key Roll Note I have more slides than minutes. All of the slides are new, I plan to skip some based on how the discussion goes 2

3 Background The next slides set up the importance of talking about the change of the KSK 3

4 For Engineers Who Don't Like Protocols What is the IPv4 address for The IPv4 address for is W.X.Y.Z 4

5 Details, Details The DNS is not client- server, not like the Web DNS has "authorita=ve" (source) servers and "recursive" (cache) servers Answers may come from the true source or a copy, rules govern what is allowed But not everyone follows rules 5

6 DNSSEC for Those Who Don't Like Protocols What is the IPv4 address for The IPv4 address for is W.X.Y.Z Digital signature by nic.se covering answer 6

7 A key Besides the data and signature, need a key to validate Need the key to be trustworthy (or it is useless) 7

8 Crypto- checking a Signature The IPv4 address for is W.X.Y.Z Digital signature by nic.se covering answer nic.se KEY ZSK? OR 8

9 What if it's? Bad things for network operators Trouble =ckets Whereever the user (ops' customers) wants to go is "down" Address is not handed to applica=on (it's broken) Applica=on can't tell it is a security problem This is why, ul=mately, this talk ma^ers 9

10 DNSSEC is more than Crypto Don't get the idea that DNSSEC only does a cryptographic check on the data, signature, and key There's about a dozen other things to check Details, details Remember, crypto is a security tool, not security 10

11 At the source nic.se KEY ZSK This gap is inten=onal The IPv4 address for is W.X.Y.Z Digital signature by nic.se covering answer The IPv6 address for is W::Z Digital signature by nic.se covering answer 11

12 Problem: Scaling and Trust "nic.se" isn't the only place to go The DNS is arranged as a hierarchy (a tree) Copying the key from the source is easy but establishing it is "true" is hard "Just because I say so" doesn't work in security 12

13 DNS is hierarchical The Root Other TLDs SE (TLD) Other SE's NIC.SE 13

14 To scale trust In DNSSEC two roles for keys were invented Zone Data Signing Key (ZSK) Key Signing Key (KSK) And at the point of delega=on (parent) Designated Signer (DS) Not a key, a pointer to a key 14

15 How this Works (DNSSEC) The Root root KEY KSK root KEY ZSK se DS Other TLDs Other SE's SE (TLD) NIC.SE se KEY KSK se KEY ZSK nic.se DS nic.se KEY KSK nic.se KEY ZSK 15

16 How this Works (DNS) The Root root SOA root NS se NS Other TLDs Other SE's SE (TLD) NIC.SE se SOA se NS nic.se NS nic.se SOA nic.se NS 16

17 What's really at the source nic.se KEY ZSK nic.se KEY KSK The IPv4 address for is W.X.Y.Z Digital signature by nic.se covering answer The IPv6 address for is W::Z Digital signature by nic.se covering answer <...>.nic.se DS 17

18 Chain of Trust The purple boxes show how a "chain of trust" is built leading to the key If one trusts the root zone's KSK key, links can be made to the nic.se ZSK, signing the data 18

19 Trus=ng the root KSK The lifecycle of the root KSK From crea=on to destruc=on Use Risks The distribu=on of the root KSK Via website Embedded in code Out of band due- diligence root KEY KSK root KEY ZSK se DS se KEY KSK se KEY ZSK nic.se DS nic.se KEY KSK nic.se KEY ZSK 19

20 Principles of Root Zone KSK opera=ons The next slides cover how ICANN manages the KSK today 20

21 ICANN's role ICANN performs the management of the root zone KSK as part of fulfilling the IANA Func=ons Contract The IANA Func=ons Contract is managed by the US Department of Commerce's Na=onal Telecommunica=ons and Informa=on Administra=on (NTIA) 21

22 DNSSEC at the Root Zone ICANN IANA Func=ons Operator Manages KSK opera=ons NTIA Root Zone Administrator Verisign - Root Zone Maintainer Manages ZSK opera=ons 22

23 Principles of Design Build Community's Trust in KSK Ac=ve external par=cipa=on 21 volunteers to fill roles (described later) Third party review SysTrust/SOC- 3 submission Emphasize incident detec=on over preven=on Choose protec=ons that can't be "fixed" ajerwards Mul=- party staff opera=ons Disaster recovery in face of travel ban ("no- fly") 23

24 A Secure Founda=on The machinery for the Root Zone KSK opera=ons include Data center, nested levels of access (cage, safes, compartments) Computer hardware configured to be air- gapped, only needed features, all sojware available for open review All opera=ons involving the private keys are recorded, tamper evident enclosures to detect lapses Published DNSSEC Prac=ces Statement 24

25 Acknowledgement Some of the folks involved in the original design 25

26 Yet Another Detail About Keys Each "DNSSEC Key" is really a pair of keys Private and Public are roles (too) Private and Public keys are specially bonded together, what one encrypts, the other decrypts and vice versa KEY KSK Public KEY ZSK Public KEY KSK Private KEY ZSK Private 26

27 Key Ceremonies To expose any use of the KSK (private key) Each =me KSK is put in ac=on is during a ceremony In- person witnesses, reviewers, streamed video Archives ( Between ceremonies, all KSK assets are kept in tamper- evident states Ceremony "explains" when seals are broken 27

28 Root Zone KSK Crea=on Created in June 2010 Installed into two HSMs in Culpeper, Virginia, US (June 16, 2010) Signed first Root Zone ZSKs Copied into two more HSMs in El Segundo, California, US (July 12, 2010) Signed second set of Root Zone ZSKs Video, ar=facts available on- line h^ps:// 28

29 Use of the KSK since then Culpepper facility Odd numbered ceremonies, spring and fall Every 6 months Alternate HSM in use (inspect tamper evidence each ceremony) El Segundo facility Even numbered ceremonies, winter and summer Same as above 29

30 Photo Montage of First Ceremonies 30

31 What's an HSM? Hardware Security Module People like to talk about them, but they aren't that interes=ng Role is to prevent anyone from seeing the private component of a key HSM creates key, generates signatures, wraps key, and many other func=ons 31

32 It's not the key, it's the HSM The HSM makes stealing the key imprac=cal But you can steal the HSM How is it protected? Physical security "Igni=on" security 32

33 Protec=on of the Root Zone KSK Availability protec=on Seven recovery key shares distributed to chosen shareholders In case of HSM "fleet" destruc=on/failure Access protec=on Physical access, many levels of access needed "Igni=on" security for HSM Three- of- seven crypto offices needed to turn on the HSM 33

34 Emphasis on Public Par=cipa=on Seven Recovery Key share holders Non- ICANN staff, individuals selected via a process in 2010, located around the globe Annual verifica=on of the shares Five- of- seven shares needed to reassemble Two sets of Seven Crypto Officers Non- ICANN staff, as above One set for Culpeper, one for El Segundo Three- of- seven needed to start an HSM 34

35 Recovery Envelope At the =me a KSK (private) key is used Signatures are generated for the next calendar quarter This allows about 3 months (give or take) of recovery =me in face of a failure It's important to note this to avoid panic 35

36 Change History HSM There's a given assump=on that a cri=cal internal ba^ery will last 5 years At the 5 year mark a "tech(nical) refresh" occurred KSK The KSK has never been changed since it's crea=on in

37 Why change the KSK? Secrets eventually become Forgo^en (all HSMs crushed) Exposed (private key copied out of HSM) Discovered (someone reverse engineers it) Will that happen soon? Probably not. But what happens if it does? Prepara=on/Prac=ce or Panic! 37

38 Valida=on Considera=ons The next few slides look at the Root Zone KSK from the "consumer" side of the opera=on 38

39 Changing the Perspec=ve DNSSEC is designed to protect the receiver of the informa=on The past slides covered the supplier of the informa=on Its =me to change the perspec=ve and look at this from the consumer's point of view 39

40 Validators Who runs this? The IPv4 address for is W.X.Y.Z Digital signature by nic.se covering answer? nic.se KEY ZSK 40

41 Validator Operators Large providers Open public managed valida=ng servers ISPs/LIRs Usually bundled service like (used to be) Enterprises/ins=tu=ons Corpora=ons, university campus Any one with a computer Down load open source and run it 41

42 State of Valida=on Growing (faster than IPv6!) Most recent measurement I saw was 14% of lookups involved DNSSEC (frankly, that's just a number) No one has a roster of all those doing valida=on (good, but makes managing harder) 42

43 What is Needed to do DNSSEC DNS sojware The root zone KSK public key (or other keys lower in the tree) Lots of pa=ence, sufficient clue 43

44 Gesng the Root Zone KSK One can servers.net. DNSKEY' and pull the key with flags=257 From there is a page where the the KSK is available But if you rely on that, you aren't really securing yourself. 44

45 Mixing Sources It's be^er to rely on a mix of sources, in case any one source has a corrupted key Out of band is also desirable, because an a^ack on the DNS is meant to steer one away from the real, true keys Note no recommenda=on is made here 45

46 Maintaining the Root Zone KSK Once a trusted KSK is on hand there is a means to check if it is current and/or if there is a successor Process and protocol specified in RFC 5011, "Automated Updates of DNSSEC Trust Anchors" 46

47 "RFC 5011" ICANN will follow the process in RFC 5011 RFC 5011 more or less says this Introduce a new key for 30 days Once the key has been seen for that long, signed by the old key, it can be trusted A key can be revoked by changing flags and self- signing it's record There is a protocol defini=on but one can follow the spirit of this separately 47

48 Why Follow RFC 5011 only in Spirit? RFC 5011's protocol counts on a DNS validator changing it's configura=on Change management systems prefer to push out configura=ons to servers like validators Instead of having the validator "do" RFC 5011, a NOC can "do" RFC 5011 and then push out the new keys in the spirit of the protocol. 48

49 Rolling the Root Zone KSK These final slides talk about the reason this is not a simple task Why there's need for communica=on amongst many par=es 49

50 Design Team To cover more ground ICANN has engaged a external, volunteer Design Team Draj report was open for an ICANN formal public comment from 6 August to 5 October 2015 Now closed h^ps:// comments/root- ksk en Design Team is preparing to review comments and include other factors A final report will be made available when ready 50

51 Impact of Rolling the KSK When ICANN, as IANA Func=ons Operator, makes a change to the Root Zone KSK All validator operators have to Pay a^en=on Perform the RFC 5011 protocol Follow in the spirit of RFC 5011 Or update systems accordingly If not, there will be trouble =ckets galore 51

52 Who Calls the Shots? It is not the intent of ICANN "as the supplier" to make changes blindly But there is li^le monitoring available RFC 5011 adherence can't be measured remotely Only the operator has access to the configura=ons A fool- proof, fail- safe plan is desirable but not feasible 52

53 What Will ICANN Do? Plans are not final yet Adhere to RFC 5011's protocol Publish new keys outside the DNS following the spirit of RFC 5011 Strive to publicize the event well in advance, minding prepara=on =me Work in concert with impacted par=es to avoid trouble =ckets 53

54 What will help ICANN? Knowing whom to inform Building a contact list of those who "pull the levers" Knowing how operators establish trust What third par=es are trusted, how many are needed? Knowing how to gauge readiness to roll 54

55 When Will All This Happen? Don't know yet. "It's complicated." But we are preparing for the change. 55

56 For more informa=on Join the mailing list h^ps://mm.icann.org/mailman/lis=nfo/root- dnssec- announce Follow on Twi^er Hashtag: #KeyRollover for the most up to date news 56