1 / 17

DNS Security Extension

DNS Security Extension. 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

troycecil
Télécharger la présentation

DNS Security Extension

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DNS Security Extension

  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

  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

  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

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

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

  7. DNS RR Review • DNS Resource Record (RR) • Can be viewed as tuples of the form <name, TTL, class, type, data> • types: A (IP address) MX (mail servers) NS (name servers) PTR (reverse look up)RRSIG (signature) DNSKEY(public key) …

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

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

  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

  11. Key Management PKedu DS Record NS for .edu Want to change PKusf to PKusf2 PKusf2 PKusf PKusf2 sign Sig{PKusf }PKedu Do not need to notify parent if changed PKsigning … NS for usf.edu

  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

  13. PKB is Bob’s public key SSL/TLS I am Alice I am Bob, inc PKB E(PKB , s) {m}KC || MACKM(m) Alice Bob KC, KM = h(s)

  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

  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…”

  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

  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

More Related