Understanding Dnscurve D. J. Bernstein University of Illinois At

Understanding DNSCurve DNS in a nutshell D. J. Bernstein 1 Browser ! DNS: twitter.com? University of Illinois at Chicago & Technische Universiteit Eindhoven

Disclaimer: I haven’t released DNSCurve software yet. But you can try prototypes: @mdempsky’s DNSCurve cache, @hhavt’s CurveDNS server. See also related projects: NaCl, DNSCrypt, CurveCP, MinimaLT. Varying release levels. Understanding DNSCurve DNS in a nutshell D. J. Bernstein 1 Browser ! DNS: twitter.com? University of Illinois at Chicago & Technische Universiteit Eindhoven 2 DNS ! browser: twitter.com A 199.16.156.38 Disclaimer: I haven’t released DNSCurve software yet. But you can try prototypes: @mdempsky’s DNSCurve cache, @hhavt’s CurveDNS server. See also related projects: NaCl, DNSCrypt, CurveCP, MinimaLT. Varying release levels. Understanding DNSCurve DNS in a nutshell D. J. Bernstein 1 Browser ! DNS: twitter.com? University of Illinois at Chicago & Technische Universiteit Eindhoven 2 DNS ! browser: twitter.com A 199.16.156.38 Disclaimer: I haven’t released DNSCurve software yet. 0 Admin ! ns2.twitter.com: twitter.com A 199.16.156.38 But you can try prototypes: @mdempsky’s DNSCurve cache, @hhavt’s CurveDNS server. See also related projects: NaCl, DNSCrypt, CurveCP, MinimaLT. Varying release levels. Understanding DNSCurve DNS in a nutshell D. J. Bernstein 1 Browser ! DNS: twitter.com? University of Illinois at Chicago & Technische Universiteit Eindhoven 2 DNS ! browser: twitter.com A 199.16.156.38 Disclaimer: I haven’t released DNSCurve software yet. 0 Admin ! ns2.twitter.com: twitter.com A 199.16.156.38 But you can try prototypes: @mdempsky’s DNSCurve cache, 1 Browser ! ns2.twitter.com: @hhavt’s CurveDNS server. twitter.com? See also related projects: NaCl, DNSCrypt, CurveCP, MinimaLT. Varying release levels. Understanding DNSCurve DNS in a nutshell D. J. Bernstein 1 Browser ! DNS: twitter.com? University of Illinois at Chicago & Technische Universiteit Eindhoven 2 DNS ! browser: twitter.com A 199.16.156.38 Disclaimer: I haven’t released DNSCurve software yet. 0 Admin ! ns2.twitter.com: twitter.com A 199.16.156.38 But you can try prototypes: @mdempsky’s DNSCurve cache, 1 Browser ! ns2.twitter.com: @hhavt’s CurveDNS server. twitter.com? See also related projects: NaCl, 2 ns2.twitter.com ! browser: DNSCrypt, CurveCP, MinimaLT. twitter.com A 199.16.156.38 Varying release levels. Understanding DNSCurve DNS in a nutshell 3 com admin ! f.ns.com: twitter.com NS ns2... D. J. Bernstein 1 Browser ! DNS: ns2... A 204.13.250.34 twitter.com? University of Illinois at Chicago & Technische Universiteit Eindhoven 2 DNS ! browser: twitter.com A 199.16.156.38 Disclaimer: I haven’t released DNSCurve software yet. 0 Admin ! ns2.twitter.com: twitter.com A 199.16.156.38 But you can try prototypes: @mdempsky’s DNSCurve cache, 1 Browser ! ns2.twitter.com: @hhavt’s CurveDNS server. twitter.com? See also related projects: NaCl, 2 ns2.twitter.com ! browser: DNSCrypt, CurveCP, MinimaLT. twitter.com A 199.16.156.38 Varying release levels. Understanding DNSCurve DNS in a nutshell 3 com admin ! f.ns.com: twitter.com NS ns2... D. J. Bernstein 1 Browser ! DNS: ns2... A 204.13.250.34 twitter.com? University of Illinois at Chicago & Technische Universiteit Eindhoven 2 DNS ! browser: twitter.com A 199.16.156.38 Disclaimer: I haven’t released DNSCurve software yet. 0 Admin ! ns2.twitter.com: twitter.com A 199.16.156.38 But you can try prototypes: @mdempsky’s DNSCurve cache, 1 Browser ! ns2.twitter.com: @hhavt’s CurveDNS server. twitter.com? See also related projects: NaCl, 2 ns2.twitter.com ! browser: DNSCrypt, CurveCP, MinimaLT. twitter.com A 199.16.156.38 Varying release levels. Understanding DNSCurve DNS in a nutshell 3 com admin ! f.ns.com: twitter.com NS ns2... D. J. Bernstein 1 Browser ! DNS: ns2... A 204.13.250.34 twitter.com? University of Illinois at Chicago & Technische Universiteit Eindhoven 2 DNS ! browser: twitter.com A 199.16.156.38 Disclaimer: I haven’t released DNSCurve software yet. 0 Admin ! ns2.twitter.com: twitter.com A 199.16.156.38 But you can try prototypes: @mdempsky’s DNSCurve cache, 1 Browser ! ns2.twitter.com: @hhavt’s CurveDNS server. twitter.com? See also related projects: NaCl, 2 ns2.twitter.com ! browser: DNSCrypt, CurveCP, MinimaLT. twitter.com A 199.16.156.38 Varying release levels. DNS in a nutshell 3 com admin ! f.ns.com: twitter.com NS ns2... 1 Browser ! DNS: ns2... A 204.13.250.34 twitter.com?

2 DNS ! browser: twitter.com A 199.16.156.38

0 Admin ! ns2.twitter.com: twitter.com A 199.16.156.38

1 Browser ! ns2.twitter.com: twitter.com?

0 Admin ! ns2.twitter.com: twitter.com A 199.16.156.38

1 Browser ! ns2.twitter.com: twitter.com?

2 ns2.twitter.com ! browser: twitter.com A 199.16.156.38 DNS in a nutshell 3 com admin ! f.ns.com: twitter.com NS ns2... 1 Browser ! DNS: ns2... A 204.13.250.34 twitter.com? 2 Browser ! f.ns.com: 2 DNS ! browser: twitter.com? twitter.com A 199.16.156.38 1 f.ns.com ! browser: twitter.com NS ns2... 0 Admin ! ns2.twitter.com: ns2... A 204.13.250.34 twitter.com A 199.16.156.38 0 Twitter admin ! ns2: 1 Browser ! ns2.twitter.com: twitter.com A 199.16.156.38 twitter.com? 1 Browser ! 204.13.250.34: ! 2 ns2.twitter.com browser: twitter.com? twitter.com A 199.16.156.38 DNS in a nutshell 3 com admin ! f.ns.com: twitter.com NS ns2... 1 Browser ! DNS: ns2... A 204.13.250.34 twitter.com? 2 Browser ! f.ns.com: 2 DNS ! browser: twitter.com? twitter.com A 199.16.156.38 1 f.ns.com ! browser: twitter.com NS ns2... 0 Admin ! ns2.twitter.com: ns2... A 204.13.250.34 twitter.com A 199.16.156.38 0 Twitter admin ! ns2: 1 Browser ! ns2.twitter.com: twitter.com A 199.16.156.38 twitter.com? 1 Browser ! 204.13.250.34: ! 2 ns2.twitter.com browser: twitter.com? twitter.com A 199.16.156.38 2 204.13.250.34 ! browser: twitter.com A 199.16.156.38 DNS in a nutshell 3 com admin ! f.ns.com: Often even more steps: twitter.com NS ns2... 1 Browser ! DNS: Maybe browser doesn’t know ns2... A 204.13.250.34 twitter.com? where .com server is. 2 Browser ! f.ns.com: Has to ask root server. 2 DNS ! browser: twitter.com? twitter.com A 199.16.156.38 1 f.ns.com ! browser: twitter.com NS ns2... 0 Admin ! ns2.twitter.com: ns2... A 204.13.250.34 twitter.com A 199.16.156.38 0 Twitter admin ! ns2: 1 Browser ! ns2.twitter.com: twitter.com A 199.16.156.38 twitter.com? 1 Browser ! 204.13.250.34: ! 2 ns2.twitter.com browser: twitter.com? twitter.com A 199.16.156.38 2 204.13.250.34 ! browser: twitter.com A 199.16.156.38 DNS in a nutshell 3 com admin ! f.ns.com: Often even more steps: twitter.com NS ns2... 1 Browser ! DNS: Maybe browser doesn’t know ns2... A 204.13.250.34 twitter.com? where .com server is. 2 Browser ! f.ns.com: Has to ask root server. 2 DNS ! browser: twitter.com? twitter.com A 199.16.156.38 1 f.ns.com ! browser: twitter.com NS ns2... 0 Admin ! ns2.twitter.com: ns2... A 204.13.250.34 twitter.com A 199.16.156.38 0 Twitter admin ! ns2: 1 Browser ! ns2.twitter.com: twitter.com A 199.16.156.38 twitter.com? 1 Browser ! 204.13.250.34: ! 2 ns2.twitter.com browser: twitter.com? twitter.com A 199.16.156.38 2 204.13.250.34 ! browser: twitter.com A 199.16.156.38 DNS in a nutshell 3 com admin ! f.ns.com: Often even more steps: twitter.com NS ns2... 1 Browser ! DNS: Maybe browser doesn’t know ns2... A 204.13.250.34 twitter.com? where .com server is. 2 Browser ! f.ns.com: Has to ask root server. 2 DNS ! browser: twitter.com? twitter.com A 199.16.156.38 1 f.ns.com ! browser: twitter.com NS ns2... 0 Admin ! ns2.twitter.com: ns2... A 204.13.250.34 twitter.com A 199.16.156.38 0 Twitter admin ! ns2: 1 Browser ! ns2.twitter.com: twitter.com A 199.16.156.38 twitter.com? 1 Browser ! 204.13.250.34: ! 2 ns2.twitter.com browser: twitter.com? twitter.com A 199.16.156.38 2 204.13.250.34 ! browser: twitter.com A 199.16.156.38 3 com admin ! f.ns.com: Often even more steps: twitter.com NS ns2... Maybe browser doesn’t know ns2... A 204.13.250.34 where .com server is. 2 Browser ! f.ns.com: Has to ask root server. twitter.com? 1 f.ns.com ! browser: twitter.com NS ns2... ns2... A 204.13.250.34 0 Twitter admin ! ns2: twitter.com A 199.16.156.38 1 Browser ! 204.13.250.34: twitter.com? 2 204.13.250.34 ! browser: twitter.com A 199.16.156.38 3 com admin ! f.ns.com: Often even more steps: twitter.com NS ns2... Maybe browser doesn’t know ns2... A 204.13.250.34 where .com server is. 2 Browser ! f.ns.com: Has to ask root server. twitter.com? twitter.com server name is ! 1 f.ns.com browser: actually ns2.p34.dynect.net. twitter.com NS ns2... Is browser allowed to accept ns2... A 204.13.250.34 ns2.p34.dynect.net address 0 Twitter admin ! ns2: from the .com server? twitter.com A 199.16.156.38 Does it have to ask .net? 1 Browser ! 204.13.250.34: twitter.com? 2 204.13.250.34 ! browser: twitter.com A 199.16.156.38 3 com admin ! f.ns.com: Often even more steps: twitter.com NS ns2... Maybe browser doesn’t know ns2... A 204.13.250.34 where .com server is. 2 Browser ! f.ns.com: Has to ask root server. twitter.com? twitter.com server name is ! 1 f.ns.com browser: actually ns2.p34.dynect.net. twitter.com NS ns2... Is browser allowed to accept ns2... A 204.13.250.34 ns2.p34.dynect.net address 0 Twitter admin ! ns2: from the .com server? twitter.com A 199.16.156.38 Does it have to ask .net? 1 Browser ! 204.13.250.34: Browser actually pulls from twitter.com? a laptop-wide DNS cache. 2 204.13.250.34 ! browser: Or a site-wide DNS cache. twitter.com A 199.16.156.38 3 com admin ! f.ns.com: Often even more steps: DNS in the real world twitter.com NS ns2... Maybe browser doesn’t know The user doesn’t want ns2... A 204.13.250.34 where .com server is. twitter.com’s IP address. 2 Browser ! f.ns.com: Has to ask root server. The user wants to twitter.com? twitter.com server name is pull tweets from Twitter, ! 1 f.ns.com browser: actually ns2.p34.dynect.net. push tweets to Twitter. twitter.com NS ns2... Is browser allowed to accept ns2... A 204.13.250.34 ns2.p34.dynect.net address 0 Twitter admin ! ns2: from the .com server? twitter.com A 199.16.156.38 Does it have to ask .net? 1 Browser ! 204.13.250.34: Browser actually pulls from twitter.com? a laptop-wide DNS cache. 2 204.13.250.34 ! browser: Or a site-wide DNS cache. twitter.com A 199.16.156.38 3 com admin ! f.ns.com: Often even more steps: DNS in the real world twitter.com NS ns2... Maybe browser doesn’t know The user doesn’t want ns2... A 204.13.250.34 where .com server is. twitter.com’s IP address. 2 Browser ! f.ns.com: Has to ask root server. The user wants to twitter.com? twitter.com server name is pull tweets from Twitter, ! 1 f.ns.com browser: actually ns2.p34.dynect.net. push tweets to Twitter. twitter.com NS ns2... Is browser allowed to accept ns2... A 204.13.250.34 ns2.p34.dynect.net address 0 Twitter admin ! ns2: from the .com server? twitter.com A 199.16.156.38 Does it have to ask .net? 1 Browser ! 204.13.250.34: Browser actually pulls from twitter.com? a laptop-wide DNS cache. 2 204.13.250.34 ! browser: Or a site-wide DNS cache. twitter.com A 199.16.156.38 3 com admin ! f.ns.com: Often even more steps: DNS in the real world twitter.com NS ns2... Maybe browser doesn’t know The user doesn’t want ns2... A 204.13.250.34 where .com server is. twitter.com’s IP address. 2 Browser ! f.ns.com: Has to ask root server. The user wants to twitter.com? twitter.com server name is pull tweets from Twitter, ! 1 f.ns.com browser: actually ns2.p34.dynect.net. push tweets to Twitter. twitter.com NS ns2... Is browser allowed to accept ns2... A 204.13.250.34 ns2.p34.dynect.net address 0 Twitter admin ! ns2: from the .com server? twitter.com A 199.16.156.38 Does it have to ask .net? 1 Browser ! 204.13.250.34: Browser actually pulls from twitter.com? a laptop-wide DNS cache. 2 204.13.250.34 ! browser: Or a site-wide DNS cache. twitter.com A 199.16.156.38 Often even more steps: DNS in the real world Maybe browser doesn’t know The user doesn’t want where .com server is. twitter.com’s IP address. Has to ask root server. The user wants to twitter.com server name is pull tweets from Twitter, actually ns2.p34.dynect.net. push tweets to Twitter. Is browser allowed to accept ns2.p34.dynect.net address from the .com server? Does it have to ask .net?

Browser actually pulls from a laptop-wide DNS cache. Or a site-wide DNS cache. Often even more steps: DNS in the real world Maybe browser doesn’t know The user doesn’t want where .com server is. twitter.com’s IP address. Has to ask root server. The user wants to twitter.com server name is pull tweets from Twitter, actually ns2.p34.dynect.net. push tweets to Twitter. Is browser allowed to accept The big picture: ns2.p34.dynect.net address DNS is just one small part from the .com server? of any real Internet protocol. Does it have to ask .net? Typical examples: Browser actually pulls from HTTP starts with DNS. a laptop-wide DNS cache. SMTP starts with DNS. Or a site-wide DNS cache. SSH starts with DNS. Often even more steps: DNS in the real world Real Internet protocol example: User asks browser for Maybe browser doesn’t know The user doesn’t want where .com server is. twitter.com’s IP address. Has to ask root server. The user wants to twitter.com server name is pull tweets from Twitter, actually ns2.p34.dynect.net. push tweets to Twitter. Is browser allowed to accept The big picture: ns2.p34.dynect.net address DNS is just one small part from the .com server? of any real Internet protocol. Does it have to ask .net? Typical examples: Browser actually pulls from HTTP starts with DNS. a laptop-wide DNS cache. SMTP starts with DNS. Or a site-wide DNS cache. SSH starts with DNS. Often even more steps: DNS in the real world Real Internet protocol example: User asks browser for Maybe browser doesn’t know The user doesn’t want where .com server is. twitter.com’s IP address. Has to ask root server. The user wants to twitter.com server name is pull tweets from Twitter, actually ns2.p34.dynect.net. push tweets to Twitter. Is browser allowed to accept The big picture: ns2.p34.dynect.net address DNS is just one small part from the .com server? of any real Internet protocol. Does it have to ask .net? Typical examples: Browser actually pulls from HTTP starts with DNS. a laptop-wide DNS cache. SMTP starts with DNS. Or a site-wide DNS cache. SSH starts with DNS. Often even more steps: DNS in the real world Real Internet protocol example: User asks browser for Maybe browser doesn’t know The user doesn’t want where .com server is. twitter.com’s IP address. Has to ask root server. The user wants to twitter.com server name is pull tweets from Twitter, actually ns2.p34.dynect.net. push tweets to Twitter. Is browser allowed to accept The big picture: ns2.p34.dynect.net address DNS is just one small part from the .com server? of any real Internet protocol. Does it have to ask .net? Typical examples: Browser actually pulls from HTTP starts with DNS. a laptop-wide DNS cache. SMTP starts with DNS. Or a site-wide DNS cache. SSH starts with DNS. DNS in the real world Real Internet protocol example: User asks browser for The user doesn’t want twitter.com’s IP address. The user wants to pull tweets from Twitter, push tweets to Twitter.

The big picture: DNS is just one small part of any real Internet protocol. Typical examples: HTTP starts with DNS. SMTP starts with DNS. SSH starts with DNS. DNS in the real world Real Internet protocol example: User asks browser for The user doesn’t want http://theguardian.com. twitter.com’s IP address. Many levels of redirection: The user wants to root DNS 7! pull tweets from Twitter, .com DNS 7! push tweets to Twitter. .theguardian.com DNS 7! The big picture: http://theguardian.com 7! DNS is just one small part http://www.theguardian.com 7! of any real Internet protocol. http://www.theguardian.com/uk. Typical examples: And then the hard work begins: HTTP starts with DNS. browser receives page, SMTP starts with DNS. displays page for user. SSH starts with DNS. DNS in the real world Real Internet protocol example: What does DNS security mean? User asks browser for The user doesn’t want Crypto goals: confidentiality, http://theguardian.com. twitter.com’s IP address. integrity, and availability Many levels of redirection: for the user’s communication. The user wants to root DNS 7! pull tweets from Twitter, Security for IP addresses .com DNS 7! push tweets to Twitter. is irrelevant unless it helps .theguardian.com DNS 7! protect user communication. The big picture: http://theguardian.com 7! DNS is just one small part http://www.theguardian.com 7! of any real Internet protocol. http://www.theguardian.com/uk. Typical examples: And then the hard work begins: HTTP starts with DNS. browser receives page, SMTP starts with DNS. displays page for user. SSH starts with DNS. DNS in the real world Real Internet protocol example: What does DNS security mean? User asks browser for The user doesn’t want Crypto goals: confidentiality, http://theguardian.com. twitter.com’s IP address. integrity, and availability Many levels of redirection: for the user’s communication. The user wants to root DNS 7! pull tweets from Twitter, Security for IP addresses .com DNS 7! push tweets to Twitter. is irrelevant unless it helps .theguardian.com DNS 7! protect user communication. The big picture: http://theguardian.com 7! DNS is just one small part http://www.theguardian.com 7! of any real Internet protocol. http://www.theguardian.com/uk. Typical examples: And then the hard work begins: HTTP starts with DNS. browser receives page, SMTP starts with DNS. displays page for user. SSH starts with DNS. DNS in the real world Real Internet protocol example: What does DNS security mean? User asks browser for The user doesn’t want Crypto goals: confidentiality, http://theguardian.com. twitter.com’s IP address. integrity, and availability Many levels of redirection: for the user’s communication. The user wants to root DNS 7! pull tweets from Twitter, Security for IP addresses .com DNS 7! push tweets to Twitter. is irrelevant unless it helps .theguardian.com DNS 7! protect user communication. The big picture: http://theguardian.com 7! DNS is just one small part http://www.theguardian.com 7! of any real Internet protocol. http://www.theguardian.com/uk. Typical examples: And then the hard work begins: HTTP starts with DNS. browser receives page, SMTP starts with DNS. displays page for user. SSH starts with DNS. Real Internet protocol example: What does DNS security mean? User asks browser for Crypto goals: confidentiality, http://theguardian.com. integrity, and availability Many levels of redirection: for the user’s communication. root DNS 7! Security for IP addresses .com DNS 7! is irrelevant unless it helps .theguardian.com DNS 7! protect user communication. http://theguardian.com 7! http://www.theguardian.com 7! http://www.theguardian.com/uk. And then the hard work begins: browser receives page, displays page for user. Real Internet protocol example: What does DNS security mean? User asks browser for Crypto goals: confidentiality, http://theguardian.com. integrity, and availability Many levels of redirection: for the user’s communication. root DNS 7! Security for IP addresses .com DNS 7! is irrelevant unless it helps .theguardian.com DNS 7! protect user communication. http://theguardian.com 7! http://www.theguardian.com 7! Consider DNSSEC marketing: http://www.theguardian.com/uk. isc.org is “signed” by DNSSEC. And then the hard work begins: browser receives page, displays page for user. Real Internet protocol example: What does DNS security mean? User asks browser for Crypto goals: confidentiality, http://theguardian.com. integrity, and availability Many levels of redirection: for the user’s communication. root DNS 7! Security for IP addresses .com DNS 7! is irrelevant unless it helps .theguardian.com DNS 7! protect user communication. http://theguardian.com 7! http://www.theguardian.com 7! Consider DNSSEC marketing: http://www.theguardian.com/uk. isc.org is “signed” by DNSSEC. And then the hard work begins: Reality: What DNSSEC signs browser receives page, is an IP-address redirection: displays page for user. isc.org A 149.20.64.69. This is meaningless for users. Real Internet protocol example: What does DNS security mean? Example of bogus “security”: User asks browser for Crypto goals: confidentiality, “You can’t trust online servers. http://theguardian.com. integrity, and availability Our DNS data is signed offline Many levels of redirection: for the user’s communication. by a Hardware Security Module root DNS 7! in a fortress in Maryland Security for IP addresses .com DNS 7! protected by machine guns. is irrelevant unless it helps .theguardian.com DNS 7! Signing procedure requires protect user communication. http://theguardian.com 7! 3 out of 16 smart cards held http://www.theguardian.com 7! Consider DNSSEC marketing: by VeriSign Trust Managers.” http://www.theguardian.com/uk. isc.org is “signed” by DNSSEC. And then the hard work begins: Reality: What DNSSEC signs browser receives page, is an IP-address redirection: displays page for user. isc.org A 149.20.64.69. This is meaningless for users. Real Internet protocol example: What does DNS security mean? Example of bogus “security”: User asks browser for Crypto goals: confidentiality, “You can’t trust online servers. http://theguardian.com. integrity, and availability Our DNS data is signed offline Many levels of redirection: for the user’s communication. by a Hardware Security Module root DNS 7! in a fortress in Maryland Security for IP addresses .com DNS 7! protected by machine guns. is irrelevant unless it helps .theguardian.com DNS 7! Signing procedure requires protect user communication. http://theguardian.com 7! 3 out of 16 smart cards held http://www.theguardian.com 7! Consider DNSSEC marketing: by VeriSign Trust Managers.” http://www.theguardian.com/uk. isc.org is “signed” by DNSSEC. And then the hard work begins: Reality: What DNSSEC signs browser receives page, is an IP-address redirection: displays page for user. isc.org A 149.20.64.69. This is meaningless for users. Real Internet protocol example: What does DNS security mean? Example of bogus “security”: User asks browser for Crypto goals: confidentiality, “You can’t trust online servers. http://theguardian.com. integrity, and availability Our DNS data is signed offline Many levels of redirection: for the user’s communication. by a Hardware Security Module root DNS 7! in a fortress in Maryland Security for IP addresses .com DNS 7! protected by machine guns. is irrelevant unless it helps .theguardian.com DNS 7! Signing procedure requires protect user communication. http://theguardian.com 7! 3 out of 16 smart cards held http://www.theguardian.com 7! Consider DNSSEC marketing: by VeriSign Trust Managers.” http://www.theguardian.com/uk. isc.org is “signed” by DNSSEC. And then the hard work begins: Reality: What DNSSEC signs browser receives page, is an IP-address redirection: displays page for user. isc.org A 149.20.64.69. This is meaningless for users. What does DNS security mean? Example of bogus “security”: Crypto goals: confidentiality, “You can’t trust online servers. integrity, and availability Our DNS data is signed offline for the user’s communication. by a Hardware Security Module in a fortress in Maryland Security for IP addresses protected by machine guns. is irrelevant unless it helps Signing procedure requires protect user communication. 3 out of 16 smart cards held Consider DNSSEC marketing: by VeriSign Trust Managers.” isc.org is “signed” by DNSSEC. Reality: What DNSSEC signs is an IP-address redirection: isc.org A 149.20.64.69. This is meaningless for users. What does DNS security mean? Example of bogus “security”: Crypto goals: confidentiality, “You can’t trust online servers. integrity, and availability Our DNS data is signed offline for the user’s communication. by a Hardware Security Module in a fortress in Maryland Security for IP addresses protected by machine guns. is irrelevant unless it helps Signing procedure requires protect user communication. 3 out of 16 smart cards held Consider DNSSEC marketing: by VeriSign Trust Managers.” isc.org is “signed” by DNSSEC. Does this protect users? No! Reality: What DNSSEC signs The web server is online, is an IP-address redirection: and most web pages are dynamic. isc.org A 149.20.64.69. The mail server is online. This is meaningless for users. The shell server is online. What does DNS security mean? Example of bogus “security”: Occasionally user data is broadcast+static+single-source, Crypto goals: confidentiality, “You can’t trust online servers. so offline creation and signing integrity, and availability Our DNS data is signed offline might help protect integrity. for the user’s communication. by a Hardware Security Module in a fortress in Maryland Security for IP addresses protected by machine guns. is irrelevant unless it helps Signing procedure requires protect user communication. 3 out of 16 smart cards held Consider DNSSEC marketing: by VeriSign Trust Managers.” isc.org is “signed” by DNSSEC. Does this protect users? No! Reality: What DNSSEC signs The web server is online, is an IP-address redirection: and most web pages are dynamic. isc.org A 149.20.64.69. The mail server is online. This is meaningless for users. The shell server is online. What does DNS security mean? Example of bogus “security”: Occasionally user data is broadcast+static+single-source, Crypto goals: confidentiality, “You can’t trust online servers. so offline creation and signing integrity, and availability Our DNS data is signed offline might help protect integrity. for the user’s communication. by a Hardware Security Module in a fortress in Maryland Security for IP addresses protected by machine guns. is irrelevant unless it helps Signing procedure requires protect user communication. 3 out of 16 smart cards held Consider DNSSEC marketing: by VeriSign Trust Managers.” isc.org is “signed” by DNSSEC. Does this protect users? No! Reality: What DNSSEC signs The web server is online, is an IP-address redirection: and most web pages are dynamic. isc.org A 149.20.64.69. The mail server is online. This is meaningless for users. The shell server is online. What does DNS security mean? Example of bogus “security”: Occasionally user data is broadcast+static+single-source, Crypto goals: confidentiality, “You can’t trust online servers. so offline creation and signing integrity, and availability Our DNS data is signed offline might help protect integrity. for the user’s communication. by a Hardware Security Module in a fortress in Maryland Security for IP addresses protected by machine guns. is irrelevant unless it helps Signing procedure requires protect user communication. 3 out of 16 smart cards held Consider DNSSEC marketing: by VeriSign Trust Managers.” isc.org is “signed” by DNSSEC. Does this protect users? No! Reality: What DNSSEC signs The web server is online, is an IP-address redirection: and most web pages are dynamic. isc.org A 149.20.64.69. The mail server is online. This is meaningless for users. The shell server is online. Example of bogus “security”: Occasionally user data is broadcast+static+single-source, “You can’t trust online servers. so offline creation and signing Our DNS data is signed offline might help protect integrity. by a Hardware Security Module in a fortress in Maryland protected by machine guns. Signing procedure requires 3 out of 16 smart cards held by VeriSign Trust Managers.” Does this protect users? No! The web server is online, and most web pages are dynamic. The mail server is online. The shell server is online. Example of bogus “security”: Occasionally user data is broadcast+static+single-source, “You can’t trust online servers. so offline creation and signing Our DNS data is signed offline might help protect integrity. by a Hardware Security Module in a fortress in Maryland But this is a rare corner case. protected by machine guns. Offline creation and signing: Signing procedure requires impossible for most user data. 3 out of 16 smart cards held by VeriSign Trust Managers.” Does this protect users? No! The web server is online, and most web pages are dynamic. The mail server is online. The shell server is online. Example of bogus “security”: Occasionally user data is broadcast+static+single-source, “You can’t trust online servers. so offline creation and signing Our DNS data is signed offline might help protect integrity. by a Hardware Security Module in a fortress in Maryland But this is a rare corner case. protected by machine guns. Offline creation and signing: Signing procedure requires impossible for most user data. 3 out of 16 smart cards held By insisting on signatures, by VeriSign Trust Managers.” DNSSEC creates problems for Does this protect users? No! lookups of dynamic DNS data; The web server is online, lookups of nonexistent names; and most web pages are dynamic. speed; robustness; availability; The mail server is online. freshness; confidentiality. The shell server is online. Analogy: imagine HTTPSEC. Example of bogus “security”: Occasionally user data is DNSCurve, CurveCP, etc. broadcast+static+single-source, “You can’t trust online servers. so offline creation and signing Our DNS data is signed offline might help protect integrity. by a Hardware Security Module in a fortress in Maryland But this is a rare corner case. protected by machine guns. Offline creation and signing: Signing procedure requires impossible for most user data. 3 out of 16 smart cards held By insisting on signatures, by VeriSign Trust Managers.” DNSSEC creates problems for Does this protect users? No! lookups of dynamic DNS data; The web server is online, lookups of nonexistent names; and most web pages are dynamic. speed; robustness; availability; The mail server is online. freshness; confidentiality. The shell server is online. Analogy: imagine HTTPSEC. Example of bogus “security”: Occasionally user data is DNSCurve, CurveCP, etc. broadcast+static+single-source, “You can’t trust online servers. so offline creation and signing Our DNS data is signed offline might help protect integrity. by a Hardware Security Module in a fortress in Maryland But this is a rare corner case. protected by machine guns. Offline creation and signing: Signing procedure requires impossible for most user data. 3 out of 16 smart cards held By insisting on signatures, by VeriSign Trust Managers.” DNSSEC creates problems for Does this protect users? No! lookups of dynamic DNS data; The web server is online, lookups of nonexistent names; and most web pages are dynamic. speed; robustness; availability; The mail server is online. freshness; confidentiality. The shell server is online. Analogy: imagine HTTPSEC. Example of bogus “security”: Occasionally user data is DNSCurve, CurveCP, etc. broadcast+static+single-source, “You can’t trust online servers. so offline creation and signing Our DNS data is signed offline might help protect integrity. by a Hardware Security Module in a fortress in Maryland But this is a rare corner case. protected by machine guns. Offline creation and signing: Signing procedure requires impossible for most user data. 3 out of 16 smart cards held By insisting on signatures, by VeriSign Trust Managers.” DNSSEC creates problems for Does this protect users? No! lookups of dynamic DNS data; The web server is online, lookups of nonexistent names; and most web pages are dynamic. speed; robustness; availability; The mail server is online. freshness; confidentiality. The shell server is online. Analogy: imagine HTTPSEC. Occasionally user data is DNSCurve, CurveCP, etc. broadcast+static+single-source, so offline creation and signing might help protect integrity. But this is a rare corner case. Offline creation and signing: impossible for most user data. By insisting on signatures, DNSSEC creates problems for lookups of dynamic DNS data; lookups of nonexistent names; speed; robustness; availability; freshness; confidentiality. Analogy: imagine HTTPSEC. Occasionally user data is DNSCurve, CurveCP, etc. broadcast+static+single-source, Most Internet connections today so offline creation and signing have no cryptographic protection. might help protect integrity. But this is a rare corner case. Offline creation and signing: impossible for most user data. By insisting on signatures, DNSSEC creates problems for lookups of dynamic DNS data; lookups of nonexistent names; speed; robustness; availability; freshness; confidentiality. Analogy: imagine HTTPSEC. Occasionally user data is DNSCurve, CurveCP, etc. broadcast+static+single-source, Most Internet connections today so offline creation and signing have no cryptographic protection. might help protect integrity. The big plan: replace But this is a rare corner case. DNS with DNSCurve, Offline creation and signing: TCP with CurveCP, impossible for most user data. HTTP with HTTPCurve, etc. By insisting on signatures, DNSSEC creates problems for lookups of dynamic DNS data; lookups of nonexistent names; speed; robustness; availability; freshness; confidentiality. Analogy: imagine HTTPSEC. Occasionally user data is DNSCurve, CurveCP, etc. broadcast+static+single-source, Most Internet connections today so offline creation and signing have no cryptographic protection. might help protect integrity. The big plan: replace But this is a rare corner case. DNS with DNSCurve, Offline creation and signing: TCP with CurveCP, impossible for most user data. HTTP with HTTPCurve, etc. By insisting on signatures, All client data is authenticated + DNSSEC creates problems for encrypted to server’s public key lookups of dynamic DNS data; from client’s public key. lookups of nonexistent names; speed; robustness; availability; All server data is authenticated + freshness; confidentiality. encrypted to client’s public key Analogy: imagine HTTPSEC. from server’s public key. Occasionally user data is DNSCurve, CurveCP, etc. Crypto layer is very close broadcast+static+single-source, to network layer. Most Internet connections today so offline creation and signing have no cryptographic protection. Each packet is authenticated + might help protect integrity. encrypted just before it is sent. The big plan: replace But this is a rare corner case. Each packet is verified + DNS with DNSCurve, Offline creation and signing: decrypted immediately TCP with CurveCP, impossible for most user data. after it is received. HTTP with HTTPCurve, etc. By insisting on signatures, All client data is authenticated + DNSSEC creates problems for encrypted to server’s public key lookups of dynamic DNS data; from client’s public key. lookups of nonexistent names; speed; robustness; availability; All server data is authenticated + freshness; confidentiality. encrypted to client’s public key Analogy: imagine HTTPSEC. from server’s public key. Occasionally user data is DNSCurve, CurveCP, etc. Crypto layer is very close broadcast+static+single-source, to network layer. Most Internet connections today so offline creation and signing have no cryptographic protection. Each packet is authenticated + might help protect integrity. encrypted just before it is sent. The big plan: replace But this is a rare corner case. Each packet is verified + DNS with DNSCurve, Offline creation and signing: decrypted immediately TCP with CurveCP, impossible for most user data. after it is received. HTTP with HTTPCurve, etc. By insisting on signatures, All client data is authenticated + DNSSEC creates problems for encrypted to server’s public key lookups of dynamic DNS data; from client’s public key. lookups of nonexistent names; speed; robustness; availability; All server data is authenticated + freshness; confidentiality. encrypted to client’s public key Analogy: imagine HTTPSEC. from server’s public key. Occasionally user data is DNSCurve, CurveCP, etc. Crypto layer is very close broadcast+static+single-source, to network layer. Most Internet connections today so offline creation and signing have no cryptographic protection. Each packet is authenticated + might help protect integrity. encrypted just before it is sent. The big plan: replace But this is a rare corner case. Each packet is verified + DNS with DNSCurve, Offline creation and signing: decrypted immediately TCP with CurveCP, impossible for most user data. after it is received. HTTP with HTTPCurve, etc. By insisting on signatures, All client data is authenticated + DNSSEC creates problems for encrypted to server’s public key lookups of dynamic DNS data; from client’s public key. lookups of nonexistent names; speed; robustness; availability; All server data is authenticated + freshness; confidentiality. encrypted to client’s public key Analogy: imagine HTTPSEC. from server’s public key. DNSCurve, CurveCP, etc. Crypto layer is very close to network layer. Most Internet connections today have no cryptographic protection. Each packet is authenticated + encrypted just before it is sent. The big plan: replace Each packet is verified + DNS with DNSCurve, decrypted immediately TCP with CurveCP, after it is received. HTTP with HTTPCurve, etc. All client data is authenticated + encrypted to server’s public key from client’s public key. All server data is authenticated + encrypted to client’s public key from server’s public key. DNSCurve, CurveCP, etc. Crypto layer is very close to network layer. Most Internet connections today have no cryptographic protection. Each packet is authenticated + encrypted just before it is sent. The big plan: replace Each packet is verified + DNS with DNSCurve, decrypted immediately TCP with CurveCP, after it is received. HTTP with HTTPCurve, etc. Much less invasive than DNSSEC All client data is authenticated + for DNS protocol, DNS databases, encrypted to server’s public key DNS implementations. from client’s public key. Also easy for HTTP etc. All server data is authenticated + encrypted to client’s public key from server’s public key. DNSCurve, CurveCP, etc. Crypto layer is very close to network layer. Most Internet connections today have no cryptographic protection. Each packet is authenticated + encrypted just before it is sent. The big plan: replace Each packet is verified + DNS with DNSCurve, decrypted immediately TCP with CurveCP, after it is received. HTTP with HTTPCurve, etc. Much less invasive than DNSSEC All client data is authenticated + for DNS protocol, DNS databases, encrypted to server’s public key DNS implementations. from client’s public key. Also easy for HTTP etc. All server data is authenticated + Separate authenticator on every encrypted to client’s public key packet also improves availability. from server’s public key. No more RST attacks. DNSCurve, CurveCP, etc. Crypto layer is very close How does server obtain to network layer. client’s public key? Most Internet connections today have no cryptographic protection. Each packet is authenticated + encrypted just before it is sent. The big plan: replace Each packet is verified + DNS with DNSCurve, decrypted immediately TCP with CurveCP, after it is received. HTTP with HTTPCurve, etc. Much less invasive than DNSSEC All client data is authenticated + for DNS protocol, DNS databases, encrypted to server’s public key DNS implementations. from client’s public key. Also easy for HTTP etc. All server data is authenticated + Separate authenticator on every encrypted to client’s public key packet also improves availability. from server’s public key. No more RST attacks. DNSCurve, CurveCP, etc. Crypto layer is very close How does server obtain to network layer. client’s public key? Most Internet connections today have no cryptographic protection. Each packet is authenticated + encrypted just before it is sent. The big plan: replace Each packet is verified + DNS with DNSCurve, decrypted immediately TCP with CurveCP, after it is received. HTTP with HTTPCurve, etc. Much less invasive than DNSSEC All client data is authenticated + for DNS protocol, DNS databases, encrypted to server’s public key DNS implementations. from client’s public key. Also easy for HTTP etc. All server data is authenticated + Separate authenticator on every encrypted to client’s public key packet also improves availability. from server’s public key. No more RST attacks. DNSCurve, CurveCP, etc. Crypto layer is very close How does server obtain to network layer. client’s public key? Most Internet connections today have no cryptographic protection. Each packet is authenticated + encrypted just before it is sent. The big plan: replace Each packet is verified + DNS with DNSCurve, decrypted immediately TCP with CurveCP, after it is received. HTTP with HTTPCurve, etc. Much less invasive than DNSSEC All client data is authenticated + for DNS protocol, DNS databases, encrypted to server’s public key DNS implementations. from client’s public key. Also easy for HTTP etc. All server data is authenticated + Separate authenticator on every encrypted to client’s public key packet also improves availability. from server’s public key. No more RST attacks. Crypto layer is very close How does server obtain to network layer. client’s public key? Each packet is authenticated + encrypted just before it is sent. Each packet is verified + decrypted immediately after it is received. Much less invasive than DNSSEC for DNS protocol, DNS databases, DNS implementations. Also easy for HTTP etc. Separate authenticator on every packet also improves availability. No more RST attacks. Crypto layer is very close How does server obtain to network layer. client’s public key? Client sends it with first packet. Each packet is authenticated + encrypted just before it is sent. Each packet is verified + decrypted immediately after it is received. Much less invasive than DNSSEC for DNS protocol, DNS databases, DNS implementations. Also easy for HTTP etc. Separate authenticator on every packet also improves availability. No more RST attacks. Crypto layer is very close How does server obtain to network layer. client’s public key? Client sends it with first packet. Each packet is authenticated + encrypted just before it is sent. How does client obtain Each packet is verified + server’s public key? decrypted immediately after it is received. Much less invasive than DNSSEC for DNS protocol, DNS databases, DNS implementations. Also easy for HTTP etc. Separate authenticator on every packet also improves availability. No more RST attacks. Crypto layer is very close How does server obtain to network layer. client’s public key? Client sends it with first packet. Each packet is authenticated + encrypted just before it is sent. How does client obtain Each packet is verified + server’s public key? decrypted immediately Client already had mechanism after it is received. to obtain server address. Server sneaks public key Much less invasive than DNSSEC into that mechanism. for DNS protocol, DNS databases, DNS implementations. Also easy for HTTP etc. Separate authenticator on every packet also improves availability. No more RST attacks. Crypto layer is very close How does server obtain to network layer. client’s public key? Client sends it with first packet. Each packet is authenticated + encrypted just before it is sent. How does client obtain Each packet is verified + server’s public key? decrypted immediately Client already had mechanism after it is received. to obtain server address. Server sneaks public key Much less invasive than DNSSEC into that mechanism. for DNS protocol, DNS databases, DNS implementations. No extra packets. Also easy for HTTP etc. Serious crypto for each packet, but state-of-the-art crypto Separate authenticator on every (Curve25519, Salsa20, Poly1305) packet also improves availability. easily keeps up with the network. No more RST attacks.