170 likes | 199 Views
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
E N D
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
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
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
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
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
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) …
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
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
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
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
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
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)
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
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…”
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
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