-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Paul,
On 14/03/15 01:19, Paul Hoffman wrote: > 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. Yes senders can send packets to the server that has to spend CPU on that. Could perhaps a different algorithm, like ED25519, provide better performance, and would that performance then be adequate? The draft allows negotiation of a symmetric key so normally a lot of asymmetric operations can be avoided by the use of a cache. For a cookie mechanism, there is the cookie draft from Eastlake and Andrews. That solves other denial of service issues as well. And use rate limiting on un-cookied-asymmetric crypto. The size is not really unbounded, because of UDP limits; but yes there are no particular restrictions on size. And it could work over TCP too. Are restrictions on size necessary? > > 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. Yes it is a good idea to look at TLS and see what protection mechanisms are missing from this simple 'encrypt DNS packet' draft. Changing to TCP only is not really the main thrust for this draft. However, it does work over TCP (if for some reason the exchange is using TCP for larger data). How is the exponentiation more expensive than TLS? It still requires asymmetric operations to establish it, and just as many? Best regards, Wouter > > --Paul Hoffman _______________________________________________ > dns-privacy mailing list [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVCu/xAAoJEJ9vHC1+BF+NKycQAK45Ka/kXhxWhjs2C+cYShnl /CLhuvvgslq7qvtmsahSM/Xh38AcXe/NmPMJ0g2BeVqtekQEz24u1qYjagrghO0w E+vaqTvDwXTwz980rq0lK/uQGfOHPdLSOW3ZKKAKhENo43rz96XFjd+LictmwHgP HdJxF5fNDwNv/Vbji51gyIOR3U5uHu98HErXCQl/6hIZfW/DPNM46JLmZq6+h5gx xJ6C6bvTnWIlwSNPPCn28nWcRE92vev8M0hgNDrp5WaTLDJ6+3Vmfr+4y29wG8Zj GJJ8FlfAHD6LMRWihLqfZgIG0b9spbe/parnZepZa1BF4zq6w36yoyU79Xv9U4xx PE9pJln1hRicglYQTmBDQY6R0MeENU/95hPlY1JplVPJKohT1nDWJuwWMEcYUJzT QhIYu2Pw4bbgt1gpD8xIIJB6+pHBFfwETgdinp5cn2erAFTmGHSmVO6XV5n3efwD OLn3W8I+DgauEVn9YJlNvCANcq3OHI/6ln3nXPkyex8wRm7MZ5eTYCyqP0y05+4k xC0GyeWlGQJYMNumZvPJWw5c4Q+0HH6iTPf2c5liAQ0yZJn9QQI+6k2/bMxTuS9S GJ4j5lR7QjEOVd80+1I3t6QvoXaDbHFQ3Qb5mmgGU9ozIS40rBDn4mSzlBeUgltq OKS27/uvKQsRzm9gp+9z =EQ4l -----END PGP SIGNATURE----- _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
