Presentation is loading. Please wait.

Presentation is loading. Please wait.

DNS Security Extension 1. Implication of Kaminsky Attack Dramatically reduces the complexity and increases the effectiveness of DNS cache poisoning –No.

Similar presentations


Presentation on theme: "DNS Security Extension 1. Implication of Kaminsky Attack Dramatically reduces the complexity and increases the effectiveness of DNS cache poisoning –No."— Presentation transcript:

1 DNS Security Extension 1

2 Implication of Kaminsky Attack Dramatically reduces the complexity and increases the effectiveness of DNS cache poisoning –No longer needs to wait for TTL to expire –The attacker can control when and what queries are issued –A complete domain may be hijacked Even TLD’s are vulnerable –Only needs 10 secs to succeed 2

3 Short-term mitigation Increase the brute-force search space –16 bits TXID is too small and can be easily brute-forced –Randomize source port number –Use other entropy in DNS messages e.g. Letter cases in URL 3

4 Long-term Solution: DNSSEC Use public-key signature to authenticate DNS messages –Domain names already form a hierarchy –Parent signs children’s public keys –Resolver only needs to know the root public key to authenticate DNS messages 4

5 5 Borrowed from slides of Prof. Dan Massey at Colorado State University l Basic Internet Database n Maps names to IP addresses n Also stores IPv6 addresses, mail servers, service locators, Enum (phone numbers), etc. l Data organized as tree structure. n Each zone is the authority for its local data. Root educomuk ciscousfcoibm cse The Domain Name System

6 6 Adapted from slides of Prof. Dan Massey at Colorado State University l Provides a “natural” PKI n Maps zones to their keys n Parent-zone sign child zones’ keys l Keys organized as tree structure. n Each zone is the authority for its local data. n A zone’s key is only effective for its zone Root educomuk ciscousfcoibm cse DNSSEC

7 DNS RR Review DNS Resource Record (RR) –Can be viewed as tuples of the form –types: A (IP address) MX (mail servers) NS (name servers) PTR (reverse look up) RRSIG (signature) DNSKEY(public key) … 7

8 Introduce a new data type: RRSIG name TTL class type value {www.usf.edu. 82310 IN A 131.247.182.171}www.usf.edu name TTL class type covered_type {www.usf.edu. 82310 IN RRSIG A …www.usf.edu 20151216023910 20141216023910 … usf.edu. Base 64 encoding of signature} DNSSEC Records not after not before key name 8

9 Introduce a new data type: DNSKEY name TTL class type value { usf.edu. 82310 IN DNSKEY Base 64 encodingusf.edu of public key} name TTL class type covered_type { usf.edu. 82310 IN RRSIG DNSKEY …usf.edu 20151216023910 20141216023910 … edu. Base 64 encoding of signature} DNSSEC Records not after not before key name 9

10 Authenticated Non-existence What if the usf.edu server is asked the IP address of a non-existent url (e.g. foo.usf.edu)? –Can’t sign non-existence on the fly because the server does not have the private key (why?) NSEC record –“The url after eng.usf.edu is global.usf.edu” –Order all the url’s in a zone and sign all the NSEC records ahead of time –Problem: enables zone enumeration –NSEC3 addresses this concern by using hashes of zone names instead of zone names themselves 10

11 PK usf2 Sig{PK usf } PK edu sign Key Management NS for.edu NS for usf.edu PK edu PK usf DS Record PK signing Do not need to notify parent if changed … PK usf2 Want to change PK usf to PK usf2 11

12 Potential Usage of DNSSEC If successfully deployed, DNSSEC can serve as a universal Public Key Infrastructure (PKI) –Sign public keys for web sites –Sign public keys for email addresses Can this really be achieved? –Existing systems like X.509 have so far failed to provide a universal PKI –DNSSEC has a major difference from X.509 Key compromise at a node only affects a subdomain 12

13 SSL/TLS AliceBob E(PK B, s) K C, K M = h(s) PK B PK B is Bob’s public key I am Bob, inc I am Alice {m} K C || MAC K M (m)

14 DNS-based Authentication of Named Entities (DANE) Use DNSSEC to sign certain statements (DANE records) –The currently proposed DANE records address trust of TLS certificates TLSA DANE records –Yet another type of DNS resource record (RR) –Three types of statements CA Constraints Service Certificate Constraints Trust Anchor Assertion 14

15 Advantages of DANE compared with X.509 Real delegation of power –Better accountability –More flexibility –Better damage control Clearer semantics –X.509 certificate encompasses everything –DANE records only means that “this domain’s owner says…” 15

16 Problems of DNSSEC Key revocation –If a zone’s private key is compromised, the damage continues even after the key is replaced, until the parent’s cert on the key expires –Certificate revocation? All the revocation problems with public keys will apply –Issue short-term certificates instead? Then the upper-level zones will have to be more involved in maintaining the DNSSEC structure Against the initial design principles of DNS: autonomy of individual zones 16

17 Deployment Status Has been on-going for a number of years –Check status: http://www.dnssec-deployment.org/ http://www.internetsociety.org/deploy360/dnssec/ maps/ Root domain signed July, 2010 –DNSSEC now deployed at key zones including net, com, gov, and edu “Almost” ready to use at the resolver level 17


Download ppt "DNS Security Extension 1. Implication of Kaminsky Attack Dramatically reduces the complexity and increases the effectiveness of DNS cache poisoning –No."

Similar presentations


Ads by Google