Slide 1

Data You Can Trust: The Key to Information Security Dr. Burt Kaliski, Jr. Senior Vice President and CTO, Verisign 25 th HP Information Security Colloquium December 15, 2014

Slide 2

Verisign Public Full version of presentation The body of this presentation is adapted from a talk by Shumon Huque of Verisign Labs Reference: Shumon Huque. DANE & Application Uses of DNSSEC. Presented at Internet2 Technology Exchange, Indianapolis, IN, USA, October 29, 2014. http://meetings.internet2.edu/media/medialibrary/2014/11/06/2014 1029-huque-dnssec-dane.pdf 2

Slide 3

Verisign Public Agenda: Data You Can Trust The perennial question in public-key cryptography DNSSEC at a glance Application uses of DNSSEC getdns: a brief introduction Conclusion 3

Slide 4

Verisign Public Introduction: The perennial question in public- key cryptography How do I get Alices public key?

Slide 5

Verisign Public Traditional answer: Public CA model Get Alices certificate & check certificate authoritys signature

Slide 6

Verisign Public But were back to where we started How do I get the CAs public key?

Slide 7

Verisign Public Traditional answer: Trust lists Trust your app (or browser or operating system or device)

Slide 8

Verisign Public But theres still one more question How do I know that this is actually Alices CA? In other words, what data can I actually trust?

Slide 9

Verisign Public DNSSEC at a glance 9

Slide 10

Verisign Public DNSSEC at a glance Original DNS protocol wasnt built with security in mind No way to verify the authenticity of DNS data other than trusting the connection to the DNS server DNSSEC: DNS Security Extensions A system to verify the authenticity of DNS data Specifications: RFC 4033, 4034, 4035, 5155 Protects against DNS spoofing & cache poisoning Secondary benefits: Ability to store and verify cryptographic keying material in the DNS, which can be used by new & existing application protocols SSHFP, IPSECKEY, CERT, DKIM, etc. DANE family: TLSA, OPENPGPKEY, SMIMEA, etc. 10

Slide 11

Verisign Public DNSSEC at a glance Uses public key cryptography Each zone has a public and private key Typically a 2-level hierarchy (KSK and ZSK) is used for each zone Zone owner uses private key to sign the zone data, producing digital signatures for each resource record set Public key is used by DNS resolvers to validate the signatures -> proof of authenticity Public key is published in the zone Zone public keys are organized in a chain of trust that follows the DNS delegation hierarchy Resolvers authenticate signatures from the root down to the target zone containing the queried name 11

Slide 12

12. (root).edu upenn.edu www.upenn.edu recursive resolver endstation (stub resolver) 1 2 3 4 5 6 8 7 answer 1.2.3.4 Recursive Resolver is prepopulated with root DNS server addresses www.upenn.edu referral to.edu referral to upenn.edu

Slide 13

13. (root).edu upenn.edu www.upenn.edu recursive resolver endstation (stub resolver) 1 2 3 4 5 6 8 7 Recursive Resolver is prepopulated with root DNS server addresses and the roots public key referral to.edu + DS,RRSIG referral to upenn.edu + DS, RRSIG answer 1.2.3.4 + RRSIG www.upenn.edu set DO bit (has roots pubkey) answer + AD bit roots pubkey edu pubkey upenn pubkey (Also queries for DNSKEY and DS records are performed as needed)

Slide 14

Verisign Public Brief DNSSEC Deployment status DNS Root was signed in July 2010 TLDs signed [1] :.COM,.NET,.EDU,.ORG,.GOV, etc.: All TLDs: 543 of 726 (74.8%), as of October 2014 ccTLDs: 102 of 286 (36%) New gTLDs: all are signed (418 of 418) Reverse trees (in-addr.arpa and ip6.arpa) are signed Levels beneath TLDs are where more needs to be done US.GOV federal: ~ 82% [3] (Oct 2014) FISMA OMB Mandate Internet2 Higher Ed members [1] : 27 of ~ 266 (10.2%).NL (Netherlands) has over 2 million signed delegations [2].COM has over ~ 405,000 signed delegations (0.35%) [4] 14 [1] http://www.huque.com/app/dnsstat/ [2] https://xs.powerdns.com/dnssec-nl-graph/ [3] http://la51.icann.org/en/schedule/wed-dnssec/presentation-dnssec-deployment-gov-15oct14-en [4] http://statdns.com/ & http://scoreboard.verisignlabs.com/

Slide 15

Verisign Public DNSSEC Validation map (from APNIC) 15 gronggrong.rand.apnic.net/cgi-bin/worldmap

Slide 16

Verisign Public Application Uses of DNSSEC 16

Slide 17

Verisign Public Application uses of DNSSEC One of the more exciting prospects for DNSSEC is DNS- based Authentication of Named Entities (DANE) DANE can be employed to describe the association between services and their cryptographic keys, and.. Allow applications to securely obtain (authenticate) those keys and use them in application security protocols Some possible applications: SSH, SSL/TLS, HTTPS, S/MIME, PGP, SMTP, DKIM, and many others.. Existing records: SSHFP, IPSECKEY, DKIM TXT record, DANE records: TLSA, OPENPGPKEY Upcoming: SMIMEA, IPSECA, 17

Slide 18

Verisign Public DANE and the TLSA record RFC 6698: The DANE Protocol for Transport Layer Security http://tools.ietf.org/html/rfc6698 Defines a new DNS record type TLSA, that can be used for better & more secure ways to authenticate SSL/TLS certificates By specifying constraints on which CA can vouch for a certificate, or which specific PKIX end-entity certificate is valid By specifying that a service certificate or a CA can be directly authenticated in the DNS itself. 18

Slide 19

Verisign Public TLSA configuration parameters 19 Usage field: 0 PKIX-TA: CA Constraint 1 PKIX-EE: Service Certificate Constraint 2 DANE-TA: Trust Anchor Assertion 3 DANE-EE: Domain Issued Certificate Selector field: 0 Match full certificate 1 Match only SubjectPublicKeyInfo Matching type field: 0 Exact match on selected content 1 SHA-256 hash of selected content 2 SHA-512 hash of selected content Certificate Association Data: raw cert data in hex Co-exists with and Strengthens Public CA system Operation without Public CAs

Slide 20

Verisign Public Early large adopters of SMTP + DANE posteo.de mailbox.org umbkw.de bund.de denic.de freebsd.org unitybox.de debian.org, debian.net ietf.org nlnetlabs.nl nic.cz nic.ch torproject.org 20 Quite a few are large email systems in Germany. See a larger list at https://www.tlsa.info/https://www.tlsa.info/

Slide 21

Verisign Public SMIMEA Using DNSSEC to associate certificates with domain names for S/MIME https://tools.ietf.org/html/draft-ietf-dane-smime-07 S/MIME is a method of encrypting and signing MIME data used in e-mail messages The SMIMEA DNS record proposes to associate S/MIME certificates with DNS domain names Verisign DANE/SMIMEA early Mail User Agent Prototype http://la51.icann.org/en/schedule/wed-dnssec/presentation- dnssec-dane-smime-15oct14-en 21

Slide 22

Verisign Public getdns: a brief introduction A new application friendly interface to the DNS 22

Slide 23

Verisign Public getdns: a new DNS library for applications getdns: A new application-friendly interface to the DNS Get and use arbitrary data in the DNS easily Get this data securely, authenticated with DNSSEC if its available Full iterative resolver mode with validation Validating stub resolver mode Designed by application developers. Most previous APIs have been developed by DNS protocol people with less concern for the needs of app developers. 23

Slide 24

Verisign Public getdns API specification: http://getdnsapi.net/spec.html Latest revision: October 2014 Creative Commons Attribution 3.0 Unported license Opensource implementation: https://github.com/getdnsapi A joint project of Verisign Labs and NLNet Labs First release (0.1.0) in February 2014 Latest release (0.1.5) in August 2014 C library Bindings in Python, and Node.js (upcoming: go, ruby, perl) BSD 3 License 24

Slide 25

Verisign Public Conclusion 25

Slide 26

Verisign Public A question of trust, revisited How do I know that this is actually Alices CA?

Slide 27

Verisign Public New answer: Public CAs, trust lists & DANE 27 Get Alices DANE record & validate its DNSSEC signature Summary: I can trust more because I know more about what others trust

Slide 28

2014 VeriSign, Inc. All rights reserved. VERISIGN and other trademarks, service marks, and designs are registered or unregistered trademarks of VeriSign, Inc. and its subsidiaries in the United States and in foreign countries. All other trademarks are property of their respective owners.