Providing ApplicationLevel Assurances
Using DNSSEC
Suresh Krishnaswamy
SPARTA, Inc. dba Cobham
Analytic Solutions
(suresh AT sparta DOT com)
Domain Name
Service
• Internet infrastructure protocol that
provides mapping between a human
memorable name and some information
about that name (e.g. IP address)
• Hierarchical, Decentralized, Scalable,
redundant, highly available service that
makes the Internet as useful as it
currently is.
• Very easy to spoof!
Spoofing DNS Responses
•
•
Difficulty level roughly that of correctly guessing
two random 16-bit values
Difficulty is even less
•
•
•
•
… if one of the two 16-bit values is predictable
… if the two 16-bit values are not *that* random
… if name server sends out multiple queries for
the same name in parallel, with different values
for the two 16-bit values
… if some NAT device reduces the
effectiveness of any name server randomization
technique
Why is this Important
• DNS resolution is normally the first step
in most Internet communications
• Web site can be replaced with a false
site without ever touching the victim site
• E-mail can be re-routed (SPF and DKIM
also rely on the DNS)
• Login compromised through man in the
middle attack
• Any technology that relies on DNS will
be affected: Anti-spam, ENUM, SIP, etc
The DNS is
transparent
1 address = multiple DNS
lookups
Weather.com
Foxnews.com
Spoof Example
The DNSSEC Pieces
Root
Validate signed
answers using a Trust
DNS Namespace
Anchor
TA Rollover
com
Registrants/Registrar
s the
(define
edu
org
namespace)
owasp
Dnssec-tools
Resolvers
(lookup DNS data)
test
Add Secure
Delegations
EPP
extensions,
Registrar Interfaces
Zone Data Administrators/
Name Server Operators
(publish DNS content)
Sign Zones
Zone Re-signing,
Key Rollover
DNSSEC at the publication
end
• The Root is signed!
• 62/294 TLDs signed
• NET to be signed Dec 2010
• COM to be signed by March 2011
• Number of registrars are capable of accepting
secure delegation information for their
registrants.
•
About 26K production DNSSEC-enabled
zones according to SecSpider
(http://secspider.cs.ucla.edu/)
DNSSEC at the validation
end
• The Root is signed! (implies a single
Trust Anchor)
• Top 4 Swedish ISPs
• COMCAST
• UCBerkeley
DNSSEC and FISMA
• Applies to all systems that "host, store,
or process Federal information”.
• Requires DNSSEC signing of all zone
data - internal and external zones, at all
levels of the DNS tree.
• Validation required for high impact
zones only, but will soon apply to lower
impact levels.
The Last Mile
Coffee shops
Conferences
Airports
Stub
First Response
wins
Recursive NS
The Last Mile
Certain ISPs
Hotels
Recursive NS
Stub
In-application
• Central resolver
can refuse to relay
validation
bad/insecure answers and can still be
spoofed locally.
• Even if users are behind a central validating
resolver at work, they may not be when they
are traveling/using their phone to check
email.
• Provides for validation up to the application.
Important if we want to use the DNS for
bootstrapping other security mechanisms.
• Provides better error codes to the
applications
Retrofitting DNSSEC
• Internet applications have been using DNS
for over 20 years.
• Significant liberties taken when processing
error conditions based on the invalid
assumption that no further changes would
occur to the DNS.
• Example: error handling loops that do not
have proper fallback cases to default
“unknown error” handling code.
• No propagation of the DNS error code up
multiple levels of the stack.
Authentication
•
Chains
Various error codes
possible
•
A
AAAA
CNAME
•
•
Maybe the name server
failed to respond?
Multiple records may be
returned for a function
call. E.g. getaddrinfo() can
return A and AAAA;
CNAME and its target
may have completely
different authentication
chains.
Each element in the
authentication chain has
getaddrinfo(): badsign-alias.netsec.tislabs.com
its own validation status.
Towards a validator
API
• Standardizing the API
is important.
• Starting from scratch would be great, but we
have legacy code to worry about. Small code
change footprint would be nice.
• Should be possible to take advantage of new
error codes that DNSSEC returns.
• Bogus is bad, un-signed does not necessarily
mean bad, validated is generally good, you
may trust something even if you know it is
bogus, and you may decide that you won’t
accept some answers at all.
Proposed
API
• Documented in “DNSSEC Validator API”
draft-hayatnagarkar-dnsext-validator-api
• Two levels of DNSSEC-awareness
• High-level: “just tell me if I can use this
answer or not”.
• Low-level: “need more information on
why DNSSEC validation failed; was this
answer actually validated or implicitly
trusted?”.
• Different validation “contexts” for different
validation policies, if needed.
Libval and its
extensions
• C Library that implements the proposed
API
• Perl module Net::DNS::Sec::Validator
that wraps around the C library
• All available from www.dnssec-tools.org
DNSSEC-capable Apps
• Secure bootstrapping of the SSH key
through the SSHFP record
% ./ssh ssh.example.com
The authenticity of host 'ssh.example.com
(192.168.1.1)' was
validated via DNSSEC.
Warning: Permanently added
'ssh.example.com,192.168.1.1' (RSA) to the list
of known hosts.
Last login: Thu Sep 20 19:49:53 2007
Welcome to Darwin!
• SPF, MX validation
• Jabberd, wget, etc
$
Libval_shim
•
•
•
•
LD_PRELOAD-based approach for adding
DNSSEC capability to existing applications
The shim library implements most of the
commonly-used resolver functions
Applications that use these functions can
automatically become DNSSEC-capable if
they run within an LD_PRELOAD environment
with libval_shim.
Many applications are known to work out of
the box with libval_shim
Firefox with
libval_shim
Validating within a
browser
• DNS intensive application, with immediate visible
effect when resolution fails.
•
What if validation fails?
•
•
Should the user be told that this was a DNSSEC
issue?
Avoid “Security check failed. Continue?
Yes/No?”
•
•
•
•
•
Modifying Firefox
Could not merely be an extension, had to be a
patch.
Allow user to enable/disable DNSSEC. All other
policy knobs are within the validator library,
libval.
Content not loaded from domains that fail
validation
Better error messages when names do not exist.
Somewhat of a challenge to throw the error to
the user
•
•
DNS error “lost” in the stack.
Firefox does pre-fetching of names
DNSSEC-enabled
Firefox
Some DNSSEC
Indicators
Name does not exist. At
All!
Other Possibilities
• Public keys in the DNS
• Force HTTPS
• ENUM
• Gaming Community
On the phone!
N900 Users: it's “lookup” in extras-testing
•
List of Resources
http://www.dnssec-tools.org
•
•
•
•
•
Zone Maintenance Tools: zonesigner, rollerd, donuts,
mapper
Troubleshooting Utilities:, dnspktflow, validate, getds,
logwatch, test zone
Validator C library, PERL modules
http://www.dnssec-deployment.org
•
•
DNSSEC-enabled applications: firefox, thunderbird,
openssh, postfix, sendmail libspf, wget, ncftp
Blog/News site devoted to DNSSEC Deployment.
https://www.iana.org/dnssec
•
Getting the Root Key
•
•
•
•
•
•
Summary/Next Steps
We have been using DNS for the last 20 years as though it
were already secure, when it really wasn’t.
With DNSSEC we now have the basis for this security (and a
signed Root!) such that that we can begin to use DNSSEC
effectively.
It’s possible to come up with innovative ways of using
DNSSEC assurances within applications. As we develop new
APIs consider how DNSSEC can be leveraged by the higher
layers.
As a web developer do you really need to fetch those remote
javascript/css? If you do, are those names under a signed
domain?
What would you need from a DNSSEC capable browser so
that your web apps can fail “smart”?
Turn on validation!
Questions?