3. The DNSSEC Primer. Data Integrity (hashes) Authenticated Denial of Existence (NSEC,

Transcription

1 3. The DNSSEC Primer Authentication (keys, signatures) Data Integrity (hashes) Chain of Trust (root zone, when signed) Authenticated Denial of Existence (NSEC, NSEC3)

2 DNS Authoritative ROOT SERVERS TLD Authoritative NS Local cache Iterative Resolver SLD Authoritative NS Stub Resolver Local cache USER PC 1

3 DNS with DNSSEC DN NSSEC aw ware app plication ns ROOT SERVERS Local cache DNSSEC Iterative Resolver DNSSEC DNSSEC 2 TLD Authoritative NS SLD Authoritative NS 3 Stub Resolver Local cache USER PC 2

4 Authentication 1 Authentication Originator signs using own private key DNS Response Recipient authenticates response with public key of originator 3

5 Where are the keys? DNSSEC Root.info key TLDs.mobi.info..info key.trustus.info t key SLDs.trustus.info trustus.info key Key information (digest, not actual key) held by parent level in hierarchy 4

6 DNSSEC key types ROOT 2 Key Types KSK Key signing key signs Key records ZSK Zone signing key signs DNS data TLD.info.info KSK.info ZSK Root KSK Root ZSK Root ZSK.info KSK.info ZSK.trustus.info KSK SLD. KSK.trustus.info ZSK.trustus.info ZSK DNS 5

7 Chain of trust The Chain of Trust If I trust a public key, I can use that key to: 1) validate the signature and 2) verify the data Root zone key Must be trusted Root zone pointers point to lower zones Each pointer is validated with the previous validated zone key Parent zone key Extends chain of trust Root zone key binds TLD key to TLD name TLD key binds SLD key to SLD name 6

8 Integrity Authentication Originator signs using own private key DNS Response Recipient authenticates response with public key of originator 2 Integrity Originator hashes DNS response Oi Originator i signs hash husing own private key DNS Response Recipient recomputes hash h of response Recipient uses public key of originator to retrieve hash Recipient compares computed hash to received hash to validate response 7

9 Data integrity in practice Root (Trust Anchor) Returned Root ZSK.TLD KSK Signed using Root K KSK Root ZSK.info.TLD ZSK.SLD KSK.TLD KSK.TLD ZSK trustus.info RESOLVER.SLD ZSK DNS Records Name IP Address.SLD KSK.SLD ZSK Name IP Address or Does NOT Exist 8

10 DNSSEC security Authentication Oi Originator i signs using own private key DNS Response Recipient authenticates response with public key of originator Integrity Originator hashes DNS response 3 Originator signs hash using own private key Denial of Existence DNS Response Recipient recomputes hash of response Recipient uses public key of originator to retrieve hash Recipient compares computed hash to received hash to validate response Originator signs NSEC or NSEC3 recordusing own private key DNS Response Recipient authenticates response with public key of originator 9

11 Resolution with authenticated denial of existence Asserts that a name does not exist in the zone NSEC For smaller zones Better performance (speed, not footprint) NSEC3 Prevent zone walking Domains Opt In 10

12 4. Key Management Primer Focus on key rollovers

13 Key management Creation Typically handled by implementation choice Important to have a good source of randomness Storage Private key must be protected Typically not archived Access Control Usage of private key must be controlled Rollover 12

14 What is a key rollover? A key rollover will occur whenever the key owner needs to change its key pair When a key rollover occurs: Data must be re signed with new private key Everyone will need to update their validating resolvers with the new public portion of the key Why perform a key rollover? 1. As a best security practice 2. Revoke a compromised private key 3. To mitigate attacks on a private key 13

15 Key rollover types 1. Planned: publish schedules* 2. Unplanned: move unexpectedly to on deck key; announced as it happens; revoke old key 3. Emergency: a newly created key that has not yet been distributed Only approximately consider jitter and other variables Best practice Always have two sets of a keys: one active and one on deck 14

16 DNSSEC recap Extends DNS (but backward compatible) Adds digital signature to each block of response For proof of origin Adds a hash Proof that the data has not been modified in transit Largest operational impact is on zone operations For example, key rollovers DNSSECdoes notencrypt data 15

17 DNSSEC resources Afilias DNSSEC The Domain Name System Security Extensions RFC 4033: DNS Security Introduction & Requirements RFC 4034: Resource Records for the DNS Security Extensions RFC 4035: Protocol Modifications for the DNS Security Extensions DNSSEC Coalition Root signing: dnssec.org 16