Trust Infrastructure and DNSSEC Deployment

1. Trust Infrastructure and DNSSEC Deployment Allison Mankin mankin@psg.com 5th Annual PKI R&D Workshop 2006

2. Why DNSSEC • Good security is multi-layered and preventive • Multiple defense barriers in physical world • Multiple ‘layers’ in the networking world • DNS infrastructure • Providing DNSSEC extensions to raise the barrier for DNS based attacks • Provides a security barrier or an enhancement for systems and applications

3. The Problem • DNS data is too readily changed, removed or replaced between the “server” and the “client”. • This can happen in multiple places in the DNS architecture • Some places are more vulnerable than others • Vulnerabilities in DNS software make attacks easier (and software will never stop being at risk)

4. Solutiona Metaphor • Compare DNSSEC to a sealed transparent envelope. • The seal is applied by whoever closes the envelope • Anybody can read the message • The seal is applied to the envelope, not to the message • This Metaphor is the Brilliant Work of Olaf Kolkman

5. Secure DNS Query and Response (simple case) Root Server Local Server myhost.example.com com Server myhost.example.com = 192.0.2.1 Plus signature for myhost.example.com End-user example.com Server Attacker can not forge this answer without the associated private keys.

6. How Does DNSSEC Extend DNS? • DNSSEC adds four new record types: • DNSKEY - carries public key • RRSIG - carries signature of DNS information • DS - carries a signed hash of key • NSEC - signs gaps to assure non-existence • Working on one more, NSEC3 • This would provide privacy enhancement

7. DNS-Vectored Attacks in Current Events: BlackBerry Router • From RIM (January, updated 29 Mar): Under normal circumstances, this [a way that the BlackBerry Router can be shut down using a flaws in the routing protocol] should be viewed as an internal-only vulnerability because the BlackBerry Router will only communicate with the BlackBerry Infrastructure. An external user attempting to exploit this needs to manipulate Domain Name System (DNS) queries. This results in a denial of service and does not require any further action to interrupt connectivity to external services. Enterprises can mitigate the risk of DNS hijacking by creating static entries in their local DNS or HOSTS tables for the BlackBerry Infrastructure. • Pointers and info on several DNS attacks from 2005 at http://www.dnssec-deployment.org/epi.htm

8. Status of DNSSEC • Production: major server implementations of the protocols • RFCs 4033, 4034, 4035 • Not ready: some OS (Microsoft); embedded-type systems (e.g. firewalls); applications-awareness • Still in development: an extension to prevent zone-walking, an important concern for a small but key set of sites • Incremental deployment of what we’ve got currently is like setting tripwires - this is good because all past experience suggests the tripwires are needed

9. State of the art deployment: RIPE • Signed reverse tree zones (in-addr.arpa, ip6.arpa) for protection of this infrastructure • Because .arpa and root not yet signed, developed careful web and secure-mail mechanism for announcing, distributing and rolling-over the public key signing key for their zones • https://www.ripe.net/projects/disi/keys/

10. State of the art: SE • .SE was first to turn on production DNSSEC and first to receive delegations • A characteristic of their operation is their transparency of security planning • Deliberations on key length, smart card for the private keys, CA software for managing the delegations, all documented on the site • http://dnssec.nic.se/

11. Other environments • Internet2 and U.S. universities including Berkeley, Penn, MIT are in DNSSEC efforts • Campuses have many targets • DNS organizations are very active, provide many trusted secondaries

12. root • Status here is complex • Regular DNSSEC workshop at ICANN has minimal ties to IANA • The DNS technical community consensus is that incremental, large deployment is the answer and root deployment can come later, as a “pull”

13. Trust Infrastructure: SSHFP • RFC 4255 allows ssh fingerprints to be published in the DNS • SSHFP Resource Record (RR) • A replaced or modified DNS response destroys ssh host verification, so this mechanism mandates use of DNSSEC authentication • A different take: DNSSEC extensions allow DNS to vector the trust infrastructure • More of this: RFC 4025, IPSECKEY • IPSECKEY RR • DNSSEC allows opportunistic key exchange

14. Trust Infrastructure: DKIM • Domain Keys Identified Mail stores and retrieves a public key for signing of email in the DNS • The signature goal varies by use but attests a domain and often also an identity “on behalf of whom” • Given this, it is obvious that the protection of the DKIM usage in DNS is needed

15. DKIM in a Vulnerable DNS Server Mar 2005 style ISP server attack Query brisbane._dkim.example.com Y Valid reply with poisoned additional information. False .com server address installed in ISP servers - 10% of servers vulnerable Attackers ISP Server Origin Endpoint X Hypothetical attack: a new signature is added by X, whose public key resides at a false domain Y. A commercially successful DNS attack last year used the same vulnerabilities and topology.

16. Observations and conclusions • There are cost tradeoffs to deploying DNSSEC • Good studies of the computing and network costs from NLNET Labs and NIST (low-moderate, probably even taking into account size of SHA-256) • Training and operation, key management • Besides thinking of costs, consider risk-benefit • We need metrics for exploits caught by current deployments • Are there alternatives to DNSSEC for protecting DKIM? • How costly is the exploitation that occurs if we don’t have this protection?