DNSSEC live signing at scale

How CloudFlare makes DNSSEC signing on-the-fly possible.

NXDOMAIN Black Lies and NSEC shotgun.

DNS-OARC workshop in AMS on 2015-05-10
https://www.youtube.com/watch?v=YCXx0RlaokQ

Transcript

1. DNSSEC live signing at scale Filippo Valsorda
2. Why CloudFlare needs live signing • Lots (lots!) of small, light traffic zones • Heavily distributed network (34 data centers) • Dynamically generated records • Zone walking protection 2
3. Why CloudFlare needs live signing • Lots (lots!) of small, light traffic zones It would be a waste to sign all the records for all the zones over and over again when each datacenter only gets asked a fraction. 3
4. Why CloudFlare needs live signing • Lots (lots!) of small, light traffic zones • Heavily distributed network (34 data centers) We would have to continuously distribute huge amounts of RRSIG data to the edges, or sign everything everywhere. 4
5. Why CloudFlare needs live signing • Lots (lots!) of small, light traffic zones • Heavily distributed network (34 data centers) • Dynamically generated records CloudFlare generates dynamic records all the time, which can’t be predicted and signed offline!
 (think attacks rerouting, geolocation based answers) 5
6. Why CloudFlare needs live signing • Lots (lots!) of small, light traffic zones • Heavily distributed network (34 data centers) • Dynamically generated records • Zone walking protection NSEC3 does not provide any actual confidentiality. NSEC5 is not here yet. 6
7. Issues with live signing • Speed! • Negative answers • Key management 7 Constraints Keep size small, and don’t require full zonefiles
8. Our solutions! 8
9. CloudFlare’s DNS(SEC) overview • RRDNS is our in-house DNS server written in Go • Resilient against attacks and abuse • No zonefiles, records are pulled from a global distributed database • Full featured (dynamic answers, CNAME flattening, …) • DNSSEC is just a “filter” applied to the answer 9
10. Solving speed (and size): ECDSA P256 • ECDSA P256 signatures are > 3x faster than RSA1024 Measured on OpenSSL 1.0.2 on our servers • We (Vlad Krasnov) ported OpenSSL ASM to Go 21X speedup for the sign: https://go-review.googlesource.com/#/c/8968/ • Bonus: small signatures, small keys, modern crypto! • Supported by most validators, working on registrars 10
11. Standard Go crypto: BenchmarkSingleSignECDSA 832295 ns/op BenchmarkSingleSignRSA 6003261 ns/op Go with Vlad’s changes: BenchmarkSingleSignECDSA 60806 ns/op BenchmarkSingleSignRSA 3124274 ns/op https://blog.cloudflare.com/go-crypto-bridging-the-performance-gap/ Solving speed (and size): ECDSA P256 11
12. Solving speed (and size): ECDSA P256 12 RSA:
 1181 BYTES ECDSA:
 305 BYTES
13. Solving negatives: “Black Lies” • To answer a NXDOMAIN normally we need: • Database lookups for previous and next name • 2 or 3 signatures (NSEC/NSEC3) - slow and big! • Previous and next name disclosure 13
14. Solving negatives: “Black Lies” 14
15. Solving negatives: “Black Lies” • RFC 4470 introduces “white lies” for online signing: • Generate a NSEC on the name’s immediate predecessor, covering up to the successor (RFC4471) • Same with the wildcard • Solves: zone walking, database lookups • Still, 2 signatures to say one thing :( 15
16. Solving negatives: “Black Lies” 16 fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG ) \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
17. Solving negatives: “Black Lies” • Our solution: true lies. Just sign a NOERROR. 17
18. Solving negatives: “Black Lies” • Our solution: true lies. Just sign a NOERROR. • Place a NSEC on the name, cover until the successor, set only the NSEC and RRSIG bits 18
19. Solving negatives: “Black Lies” 19
20. Solving negatives: “Black Lies” • 1 signature op, no db lookup or zone walking • The entire answer fits 512 bytes (actually, < 400!) • End-user behavior is unchanged 20
21. Solving negatives: “Black Lies” • We suggest to signal the difference between a NXDOMAIN and a empty non-terminal with a special RRType in the NSEC bitmap https://datatracker.ietf.org/doc/draft-ogud-fake-nxdomain-type/ 21
22. Solving negatives: the “NSEC shotgun” • But. To answer a missing type on an existing name, we still need to query the database for the NSEC bitmap • That’s not even always possible! (Dynamic answers) 22 filippo.io. 3600 IN NSEC \003.filippo.io. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY

23. Solving negatives: the “NSEC shotgun” • Step back: what is a NSEC? A denial of existence. • “The types not in the bitmap don’t exist” • So, let’s make a “minimally covering” one.
 By setting all possible bits in the bitmap! 23 filippo.io. 3600 IN NSEC \003.filippo.io. A NS SOA WKS HINFO MX TXT AAAA LOC SRV CERT SSHFP IPSECKEY RRSIG NSEC DNSKEY TLSA HIP OPENPGPKEY SPF
24. Solving negatives: the “NSEC shotgun” • Asked for TXT and there’s no TXT? Set all the other bits that might exist. • The NSEC is a valid denial for TXT, and is useless for an attacker that wants to replay it for other queries. 24 filippo.io. 3600 IN NSEC \003.filippo.io. A NS SOA WKS HINFO MX TXT AAAA LOC SRV CERT SSHFP IPSECKEY RRSIG NSEC DNSKEY TLSA HIP OPENPGPKEY SPF
25. Solving negatives: the “NSEC shotgun” • Asked for TXT and there’s no TXT? Set all the other bits that might exist. • No useless database lookups! Actually, no need to see the database from the signer at all. 25 filippo.io. 3600 IN NSEC \003.filippo.io. A NS SOA WKS HINFO MX TXT AAAA LOC SRV CERT SSHFP IPSECKEY RRSIG NSEC DNSKEY TLSA HIP OPENPGPKEY SPF
26. Solving keys: centralized DNSKEY sets • It’s live-signing, you need the ZSK at the edge (for now) • Protect the KSK: keep it in a safe central auditable machine, distribute the signed DNSKEY sets to edges • Short regular RRSIG validity, longer for DNSKEY • Prepared to roll the ZSK fast at any time 26
27. Solving keys: global ZSK and KSK • No reason to have millions of ZSKs and KSKs:
 all would be used/stored/rolled together • Use a single KSK and a single ZSK with multiple names filippo.io. 3600 IN DNSKEY 256 3 13 koPbw9wmYZ7ggcjnQ6ayHyhHaDNMYELKTqT+qRGrZpWSccr/lBcrm10Z 1PuQHB3Azhii+sb0PYFkH1ruxLhe5g== cloudflare-dnssec-auth.com. 3600 IN DNSKEY 256 3 13 koPbw9wmYZ7ggcjnQ6ayHyhHaDNMYELKTqT+qRGrZpWSccr/lBcrm10Z 1PuQHB3Azhii+sb0PYFkH1ruxLhe5g== 27
28. Questions? 28 Filippo Valsorda filippo@cloudflare.com