Providing Application-Level Assurances Using DNSSEC

1. Providing Application-Level Assurances Using DNSSEC • Suresh Krishnaswamy • SPARTA, Inc. dba Cobham Analytic Solutions • (suresh AT sparta DOT com)

2. 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!

3. 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

4. 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

5. The DNS is transparent

6. 1 address = multiple DNS lookups Weather.com Foxnews.com

7. Spoof Example

8. The DNSSEC Pieces Root Validate signed answers using a Trust Anchor DNS Namespace TA Rollover com edu org Registrants/Registrars (define the namespace) Resolvers (lookup DNS data) Root Dnssec-tools owasp edu test Add Secure Delegations org Sign Zones EPP extensions, Registrar Interfaces Zone Re-signing, Key Rollover Zone Data Administrators/ Name Server Operators Dnssec-tools (publish DNS content) test

9. 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/)

10. DNSSEC at the validation end • The Root is signed! (implies a single Trust Anchor) • Top 4 Swedish ISPs • COMCAST • UCBerkeley

11. 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.

12. The Last Mile Actual response Coffee shops Conferences Airports Query Recursive NS Spoofed response First Response wins Stub

13. The Last Mile Actual response Certain ISPs Hotels Query Recursive NS NXDOMAIN rewriting Stub

14. In-application validation • Central resolver can refuse to relay 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

15. 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.

16. Authentication Chains A AAAA CNAME • Various error codes possible • 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 its own validation status. getaddrinfo(): badsign-alias.netsec.tislabs.com

17. 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.

18. 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.

19. 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

20. DNSSEC-capable Apps • Secure bootstrapping of the SSH key through the SSHFP record • SPF, MX validation • Jabberd, wget, etc % ./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! $

21. 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

22. Firefox with libval_shim

23. 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?”

24. 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

25. DNSSEC-enabled Firefox

26. Some DNSSEC Indicators

27. Name does not exist. At All!

28. Other Possibilities • Public keys in the DNS • Force HTTPS • ENUM • Gaming Community

29. On the phone! N900 Users: it's “lookup” in extras-testing

30. List of Resources • http://www.dnssec-tools.org • DNSSEC-enabled applications: firefox, thunderbird, openssh, postfix, sendmail libspf, wget, ncftp • 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 • Blog/News site devoted to DNSSEC Deployment. • https://www.iana.org/dnssec • Getting the Root Key

31. 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!

32. Questions?