DNS Security

Fundamental Problems of Network Security Internet was designed without security in mind Initial design focused more on how to make it work, than on how to prevent abuses Initial environment mostly consisted of research institutions---assumption on the benign behaviors of users Fundamental security problem of current network technology: Has no way of telling whether the resource is located “correctly,” or the information is transferred “correctly” Has no data authentication and confidentiality protection

Example Security Problems by Incorrect Resource Location DNS poisoning BGP routing vulnerabilities ARP poisoning ARP (Address Resolution Protocol) is used to query for the MAC address associated with an IP address Any device attached physically to a subnet can claim to be the “owner” of the IP IP Spoofing Routers typically do not check source IP addresses A packet can claim to be coming from any IP address Routers have no good way to check IP addresses either

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 www Adapted from slides of Prof. Dan Massey at Colorado State University

Domain Name Service Provides binding between URL and IP address Both forward and reverse mapping Divide URL space into zones; Each name server handles mapping in its zone 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)

DNS Protocol ISP What is the IP address of www.usf.edu? root Server Go ask 192.41.162.30 What is the IP address of www.usf.edu? ISP NS Server for edu (192.41.162.30) What is the IP address of www.usf.edu? Go ask 131.247.100.1 What is the IP address of www.usf.edu? 131.247.182.171 ISP’s DNS Resolver NS Server for usf.edu (131.247.100.1)

Example Response from the .edu NS server Delegation of authority ;; QUESTION SECTION: ;www.usf.edu. IN A ;; AUTHORITY SECTION: usf.edu. 172800 IN NS mother.usf.edu. usf.edu. 172800 IN NS ziggy.usf.edu. usf.edu. 172800 IN NS clemson-ns1.usf.edu. ;; ADDITIONAL SECTION: mother.usf.edu. 172800 IN A 131.247.100.1 ziggy.usf.edu. 172800 IN A 131.247.1.40 clemson-ns1.usf.edu. 172800 IN A 205.186.58.129 … Glue records

DNS Security Problems A DNS resolver has no way to determine if the response of a query does come from the legitimate server It will accept a response if The port number matches the source port of the request Has the correct Transaction ID (TXID). It will accept all RR’s that are in the queried server’s bailiwick The bailiwick is the domain in which the server has authority according to the referral path

Classical DNS Poisoning DoS flooding DNS queries ISP faked responses What is the IP address of www.usf.edu? What is the IP address of www.usf.edu? recursive query 131.247.182.171 Recursive DNS resolver NS Server for usf.edu

Conditions for classical DNS poisoning attacks Must guess right the correct source-port number Must guess right the correct TXID (16 bits) The fake response must arrive before the legitimate response If any of the above fails, the attack fails and there will be no chance to attack again until the TTL expires

Kaminsky Attack (2008) 1.1.1.1 What is the IP address of foo.usf.edu? usf.edu. NS www.usf.edu www.usf.edu A 1.1.1.1 ISP What is the IP address of foo.usf.edu? No such url Recursive DNS resolver NS Server for usf.edu

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 www Adapted from slides of Prof. Dan Massey at Colorado State University

DNSSEC Provides a “natural” PKI Keys organized as tree structure. 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 in its zone Root edu com uk usf cisco ibm co www 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 … 20171216023910 20151216023910 … usf.edu. Base 64 encoding of signature} not after not before key name

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 … 20171216023910 20151216023910 … 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 health.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 PKusf PKusf2 PKusf2 Sig{PKusf }PKedu PKsigning DS Record NS for .edu Want to change PKusf to PKusf2 PKusf PKusf2 PKusf2 sign Sig{PKusf }PKedu PKsigning Do not need to notify parent if changed NS for usf.edu …

Potential Usage of DNSSEC If successfully deployed, DNSSEC can serve as a universal PKI Sign public keys for web sites Sign public keys for email addresses

SSL/TLS I am Alice I am Bob, inc PKB is Bob’s public key 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 CA Constraints: The client should only accept certificates issued under a specific CA. Service Certificate Constraints: The client should only accept a specific certificate. Trust Anchor Assertion: The client should use a domain-provided trust anchor to validate certificates for that domain.

Advantages of DANE compared with X.509 Real delegation of power Better accountability More flexibility Better damage control Clearer semantics 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 digital signatures 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 http://www.dnssec-deployment.org/ 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