DNSSEC: From Cryptographic Design to Real Deployment

1
DNSSEC From Cryptographic Design to Real
Deployment

• Lixia Zhang
• Joint work with Dan Massey and Eric Osterweil
• October 2007

2
Why this talk

• I know very little about theoretical computer
  science ?
• Cryptographic theory has been applied in network
  systems, and my observation suggests that a big
  gap exists between crypto theory and practice
• Why a gap?
• DNS Security Extensions (DNSSEC) is used as an
  illustrative example

• Warning this talk is a one-side view of the
  picture

3
Outline

• How DNS works
• Why DNSSEC?
• The basic idea in DNSSEC design
• What didn't go right (the first time)?
• (is DNS working well today without DNSSEC?)
• What can we learn from this experience?

4
DNS Design A Great Challenge

• Goal a distributed database to provide name to
  IP address mapping, offering dependable service
• Unknowns
• Name space size? (a multiple dimension space)
• System size?
• System load?

5
The Domain Name System
Root

• Virtually every application uses DNS
• Name space a tree hierarchy
• Can grow in width and depth indefinitely
• DNS database maps
• Name to IP addresswww.darpa.mil 128.9.176.20
• And many other mappings (mail servers, enum,
  geolocation, resource discovery...)

To other TLD domains
edu
mil
cn
darpa
isi
edu
af
tsinghua
nge
andrews
itcs
6
How DNS Works

• A distributed database following the name
  hierarchy
• Each domain an administrative authority
• is authoritative for its own data
• Runs a set of authoritative servers
• Parent domain keeps name server addresses of its
  children
• DNS lookup by caching resolver
• Run by Internet service providers
• Improve scalability, performance, and service
  reliability

Root
To other TLD domains
edu
mil
cn
darpa
isi
edu
af
tsinghua
nge
andrews
7
Why DNSSEC?

• Original DNS design focused on system scalability
  and data availability
• No security consideration
• All resolvers serve all DNS queries
• All DNS responses are generally accepted.
• A number of DNS vulnerabilities identified in
  early 90's
• Some of them indeed have been exploited by
  malicious attackers

8
A Simple DNS Attack
Easy to observe UDP DNS query sent to well known
server on well known port.
www.ucla.edu A?
Root DNS Server
www.ucla.edu A 169.232.33.135
Lixias Laptop
Caching DNS Server
www.ucla.edu A 128.9.128.127
edu DNS Server
Dans Laptop
First response wins. Second response is silently
dropped on the floor.
ucla.edu DNS Server
9
A More Complex Attack
Response www.attacker.com A
128.9.128.127 attacker.com NS
ns.attacker.com attacker.com NS
www.google.com ns.attacker.com A
128.9.128.2 www.google.com A
128.9.128.127
UCLA Caching Server
www.google.com 128.9.128.127
ns.attacker.com
Query www.attacker.com
Query www.google.com
UCLA Laptop
Remote attacker
10
DNSSE in a Nutshell

• Design goal add origin authenticity and data
  integrity checking into DNS
• Approach Simple combination of DNS and public
  key cryptography
• Each zone manages its own key pair
• DNS Tree Hierarchy leveraged to form a PKI
• Configure the root's public key into all cache
  resolvers
• Parent signs children's public key
• All authoritative servers sign all DNS replies
• One design constraint all data needs to be
  pre-signed

11
Secure DNS Responses
Caching DNS Server
www.ucla.edu
Authoritative DNS Servers
www.ucla.edu
169.232.33.135 Plus (RSA) signature by the
ucla.edu private key
End-user

• Follow the DNS tree to authenticate the response
• Assume root public key is well known
• Root key signs edu key
• edu key signs ucla.edu key
• ucla.edu key signs the data

12
The puzzle

• How hard can it be to design and deploy such a
  simple crypto system?

"At the time (1993) it seemed pretty obvious and
straightforward. The scope of work was limited
and we estimated we would be done in about one
year (an estimation that, unfortunately, has
become the DNS Security mantra)." DNS Security A
Historical Perspective By James Galvin (2006)
13
History of DNSSEC

• The design went through 3 major revisions in next
  12 years
• The basic set of protocol specification finalized
  in 2005 (RFC 4033, 4034, 4035)
• Currently supported by most DNS implementations
• Yet new proposals for changes have not stopped
• Deployment
• A number of trials since year 2000
• Wide operational use is yet to come

• Why?

14
Some of the technical issues

• (not a complete list, but for illustrative
  purpose)
• Key management in a distributed system
• Key management and caching
• Offline key and dynamic updates
• Authenticating the denial of existence
• Incremental deployment
• Distributed system vs distributing expertise

15
Key management in DNS first try
Each doman stores its pub key
Root KEY record SIG by root
Now try to change this KEY
Root DNS Server
com KEY record SIG by root
Adds communication and synchronization with parent
Com DNS Server
Adds communication and synchronization with child
foo.com KEY record SIG by com
children varies between 0 and 60 million
foo.com DNS Server
16
The solution
Can Change com key without notifying foo.com
foo.com NS records
foo.com DS record (hash of pubkey 1)
foo.com SIG(DS) by com private key
com DNS Server
foo.com DNS Server
Can Change key 2 without notifying .com
foo.com KEY (pub key 1)
foo.com KEY (pub key 2)
Key1 KeySignKey Key2 ZoneSignKey
foo.com SIG(key2) by key 1
www.foo.com A record
www.foo.com SIG(A) by key 2
17
DNS Caching a fundamental challenges in key
management

• In crypto model Alice talks to Bob, with Eve as
  potential adversary in the middle

Alice
Bobs key
Eve
verification
signing
data

• In DNS Alice talks to Bob through Carol

18
Key rollover with caching

• When a key changes, cannot immediately remove the
  old key from authoritative servers
• Some caches may have stored the old signature
• Some caches may have stored old key
• Key rollover steps

19
Key revocation with caching

• Emergency key revocation is needed when a key is
  compromised
• Currently remains an open issue
• Large number of faceless caches
• Revocation list does not scale well
• Large name space ? large number of keys
• Broadcast does not scale well
• We are currently working on a solution based on
  combined opportunistic notification with periodic
  polling

20
Authentication of DNS Responses

• Each zone signs its data using a private key.
• Recommend signing done offline in advance
• Query for a particular record returns
• The requested resource record set.
• A signature (SIG) of the requested resource
  record set.
• What if the data changes dynamically?
• In that case, people keep private key online
  despite the recommendation saying otherwise

21
Authentication of DNS Responses (2)

• Each zone signs its data using a private key.
• Recommend signing done offline in advance
• Query for a particular record returns
• The requested resource record set.
• A signature (SIG) of the requested resource
  record set.
• What if the requested record doesnt exist?
• DNS returns No such name
• DNSSEC How to authenticate this, assuming reply
  cannot be signed on the fly?

22
Authenticated denial of existence
Solution sign next name after a.ucla.edu.
is g.ucla.edu.
Caching Server
foo.ucla.edu. ?
Authoritative DNS Servers
End-user
foo.ucla.edu. does not exist a.ucla.edu
NSEC g.ucla.edu. a.ucla.edu RRSIG NSEC .
23
New issues (1) raised overhead

• Effectively doubled the DNS database size
• Who cares VeriSign ( 60M domains under .com
  zone and the number going up fast)
• "why should I pay the cost while 0 customers may
  turn on DNSSEC in next few years?"
• Debate went on for two years...
• Solution changed the semantics of the record
• previous next name after a is c
• Revised next signed name after a is c

24
New issues (2) raised zone walking

• NSEC RR can be used to retrieve all the names in
  a zone!
• Another couple of years of debates on whether
  zone-walking is/not a problem
• Eventually agreed on disagreement and developed a
  solution based on hashing
• The new solution, NSEC3, is not backward
  compatible with the "standard" (RFC 4033-4035)

• Latest news "Signature Only" proposal popped
  up last year

25
Learning from reality

• DNSSEC deployment slowly rolling out
• Developed a monitoring tool to watch the rollout

26
http//secspider.cs.ucla.edu/
27
Issue 1 Inremental deployability

• Island of Security DNS sub-tree where every zone
  in the sub-tree has deployed DNSSEC
• In design, one can leverage DNS hierarchy for a
  PKI
• Result in single island of security, all zones
  deploy DNSSEC and manually configure the root key
• In practice, one cannot mandate the deployment of
  DNSSEC everywhere
• SecSpider showed that, among 10K DNSEEC-enabled
  zones, Vast majority of them are single zone
  islands
• How can a resolver learn a secure zones public
  key?

28
Addressing Islands of Security Issue

• Exploring all our options
• Infeasible to manually configure the public key
  for each island of security
• Deploying DNSSEC at all zones or at least from
  root down Has yet to happen operationally..
• Can we trust the public keys visible at the
  monitor?
• Must ensure monitor collected the correct key
• ?Can rely on distributed services and checking by
  actual admins.
• Must ensure keys came from monitor
• ?Can use readily available DNSSEC to provide
  authenticated replies

29
Issue 2 Managing crypto deployment
"Distributing authority for a database does not
distribute a corresponding amount of
expertise... The operators "want to use, not
understand, the systems they are provided." Paul
Mockapetris, SIGCOMM'88
30
Lack of crypto deployment expertise

• Establish key pair and sign the zone Relatively
  straight-forward, but issues below add challenges
• Update the key pair periodically
• Relates to cache TTL and signature lifetime
  selection
• Establish and maintain an Authentication Chain
  with a Secure Parent
• Cross-domain coordination with different
  administrations is hard, human errors inevitable

• An old issue, but a new problem
• DNS tolerates cross-domain config. Errors
• DNSSEC does not

31
Does Internet need crypto protection?

• Wide deployment of crypto protocols
• https (Secure HTTP)
• SSH (Secure Shell)
• SSL (Secure Socket Layer)
• All current deployments limited to securing
  point-to-point communications
• A long history of attempts to applying crypto to
  distributed systems such as DNS, Internet routing

32
Step up a level why a big gap?

• The clash between the rigorous crypto logic and
  the large scale and distributed nature of an open
  Internet system

33
More specifically

• (there have been DNS-specific problems, but one
  can also identify general issues)
• The first DNSSEC design was logically correct,
  but practically infeasible to implement in a
  large scale system
• Large systems heavily depend on caching in
  general, while a crypto design doesn't have a
  memory model (or have one that fits reality)
• Crypto systems consider a function exists/not
  exists, a large system is never black/white
• Crypto systems aim at rigorous "provable
  security", but don't normally take into account
  of (inevitable) errors Internet systems must
  take errors as a given
• Crypto systems assume a structured PKI, the
  Internet does not have one or fit into one
• Need a brand new direction to solve key
  authentication problem

34
What to Carry Away

• Crypto protection can be a very useful tool in
  securing Internet systems
• To add effective crypto protection to the
  Internet, we must identify and close the gap
  between crypto designs and a set of intrinsic
  natures of large scale, distributed systems

35
Thank you!
Questions?
lixia_at_cs.ucla.edu