Greetings again. I mentioned this to Wouters a while ago, before the DPRIVE WG started, but it is worth bringing up here if the WG is considering this for widespread deployment.
draft-wijngaards-dnsop-confidentialdns running over UDP opens up the server to a trivial CPU denial-of-service because the server needs to attempt to do an expensive asymmetric decryption for every request that it gets that has the ENCRYPT QTYPE and an ENCRYPT RR in the authority section. It takes no cryptographic effort for a bot client to create the hard-to-process ENCRYPT RR: the RDATA can be any random crap. Note that the RDATA size in draft-wijngaards-dnsop-confidentialdns is pretty much unbounded, because the ENCRYPT RRs in a query contain not only the actual request, but they might also hold additional ENCRYPT RRs for keys for the reply. This asymmetry (bot clients take no effort to create requests that cause the server huge CPU resources for exponentiations) makes the proposal dangerous to deploy for a server because it can't decide when to not try to decrypt. Changing draft-wijngaards-dnsop-confidentialdns over to TCP is one possibility, but even then this protocol forces a server to perform more expensive exponentiations than setting up a TLS session. Or you can re-invent IKEv2 with a cookie-like mechanism, but even then, the CPU DDoS is still an issue, although less of one. These are why people have proposed TLS as a transport: all the anti-DDoS that has been developed for secure web servers comes to secure DNS servers for free. --Paul Hoffman _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
