-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Paul,
On 20/03/15 01:59, Paul Hoffman wrote: > On Mar 19, 2015, at 8:49 AM, W.C.A. Wijngaards > <wou...@nlnetlabs.nl> wrote: >> 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. > > That's only part of the issue I raised: the bigger part is the huge > amount of CPU the client can cause the server to spend with almost > no effort on the client's part. > >> Could perhaps a different algorithm, like ED25519, provide >> better performance, and would that performance then be adequate? > > No to the latter question. Given that the client can cause an > unbounded amount of decrypting for the server, a faster algorithm > is nice but does not alleviate the problem. Thank you (and Paul) for telling me. I thought it would have been a solution, and that asymmetric crypto was fast enough for doing it all the time. There are likely many parts of solutions, in IKE, TLS, that are much better than this draft, because I do not know IKE and TLS internals. >> The draft allows negotiation of a symmetric key so normally a lot >> of asymmetric operations can be avoided by the use of a cache. > > Allows, but does not require. So, in the meantime, the attacker can > starve the server's CPU. The crypto in the packet format causes unnecessary asymmetric load. The packet format has to be fixed in some way. The client cryptographical authentication: solution space is big for this. I am also trying to avoid it, as it is not the main point now. Cookies help with identifying IPs in the DoS; and then ratelimiting can be applied. But legit IPs can continue the attack. TLS does not have this problem, but why doesn't it? The server has to do crypto for a client. And clients can start new connections by sending a (couple) packets. If cookies do not solve it, TCP also does not solve it. Is the idea that the client has to invest CPU power in computing something before the server will invest CPU power? botnets will have more cpu power than the server (just like bandwidth)... Otherwise, the solution seems to look at the protection mechanism from TLS (if it has any) and see if that can be copied. The protocol could be changed to mandate that every message has to carry the SYM key establishment, for this one packet or for more packets. That SYM key encrypts a couple bytes algorithm identifier and the crypto material for a symmetric key, thus it is small. And then change to mandate that that key is used to crypt further materials in the packet. That change may lower the CPU required for the server (and in the answer, for the client)? Best regards, Wouter > >> For a cookie mechanism, there is the cookie draft from Eastlake >> and Andrews. That solves other denial of service issues as >> well. > > No, it really doesn't in the proposal here. It just means that the > server will know which IP the attack is coming from. That's kind of > useless for a resolver that has to provide service to everyone in > an address range. > >> And use rate limiting on un-cookied-asymmetric crypto. > > At that point, this protocol becomes more complicated than TLS. > >> 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? > > This protocol has asymmetric decryption on messages *much* larger > than what are normally used for asymmetric crypto. So, yes, > restrictions are really 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. > > See above, as a start. > >> 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). > > If the protocol runs over TCP, it inherently causes either more > round trips than TLS, or much more CPU usage. That doesn't seem > like any advantage. > >> How is the exponentiation more expensive than TLS? It still >> requires asymmetric operations to establish it, and just as >> many? > > In TLS, the asymmetric calculations are done on short values only > to create a shared symmetric key. In this protocol, the asymmetric > calculations are on much longer values, and a single client message > can cause many such calculations. TLS (and IKE) were designed to > avoid that. > > --Paul Hoffman > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVC+IWAAoJEJ9vHC1+BF+NdCgQAJd4XXMhiTFUDYJc7kYCR9MK z6kCaKMsp1I3fxtJHNjQCzyGJYDFaYwY3xYJZeNcC9JBMhHy+dCUYSKCnK7jOyEh gCsNnJwP5KP423PENnoEAGKOZugaNZXh5dmr+Qd3PkOe+2EEhnBSH/+EYUl7V4sk snUL4gjO5ayYgKyy/caIRhY5DcvgTfTmJrd/hSc2w2tKfnqV/4gprV/hrFhqLz6t p6V902XaL3ctrRaxKrYudtoZ+F5g0VgMLDNabcZMoaBSCwPe3/mXQLuH7nEw1IwO Gxr17j9qnEhROP3uKKBQZrk3+xTp2Kn/BUMXSfshPQ9i1DuzCaYpkETLuVWddFxY IiUWqw8h5KV/GusRsAUZK0vS/JE1MFPx1nwFpxayNM08aDgkBP8BvWvt+zSYApkq kqTxyLgX4xDjrzZvYOAsQb1QPkwq1pj+wlNgohZP4Q/WDr68+qKvDPnVvgubELwS URjuEJuqKcd9zs/ykxqzd9os5T9sqWtUvExWtjh34KTVLs/6/w8dgKTf4iM8uz8c zW9Xa9hyyTbIzXfJoOq+z0mXcAMYRwtwjGUNySxVJJ1exDB4sW5m9VcbtfWd/Sfp vzDiLBik2OCLM2+i8CKncd58cd2X29/Rn2+LwPt/3J02ykQoH22NGRby3SPbMyX/ C2XHn8Zu86j4NtqQJQ0l =LQ37 -----END PGP SIGNATURE----- _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
