On Mar 19, 2015, at 7:00 PM, Watson Ladd <[email protected]> wrote: > > On Thu, Mar 19, 2015 at 5:59 PM, Paul Hoffman <[email protected]> wrote: >> On Mar 19, 2015, at 8:49 AM, W.C.A. Wijngaards <[email protected]> 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. > > A botnet can also spend a very small amount of bandwidth to generate > large bandwidth responses.
I was speaking only of CPU exhaustion, not bandwidth exhaustion. Nothing in this proposal makes the current bandwidth exhaustion attacks much better or worse. > Of course, the specification of multiple > possible response keys is pointless: DNSCurve had a very similar > design, without these wrinkles. I would like to know what exactly is > wrong with DNSCurve/DNScrypt as a solution to the kind of problems > we're talking about. We've asked, repeatedly, for specs on DNScrypt to consider in the WG. I don't see any in the Internet Drafts repo. > >> >>> 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. > > The current speed record for DH exchange is around 70,000 CPU cycles > on a recent Intel CPU. That means that a server can decrypt 50,000 > requests per second. It's trivial to design a mechanism by which this > exchange has to be done only when new clients connect, rather than on > every request. That speed is for 16-byte messages, yes? The proposal is has messages much larger than that, some of which require multiple asymmetric decrypts. >>> 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. >> >>> 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. > > Why can't a resolver stop serving abusive clients? Because it can't identify them early enough, given the way that the protocol allows many decrypts needed per query. > >> >>> 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. > > Is decrypting 32 bytes encrypted ECIES (or say crypto_box) actually > faster than decrypting 1024 bytes? The answer is "by epsilon": once > the asymmetric key is computed, it is reused, and the time difference > is for encrypting with AES. Of course, the draft doesn't actually > specify *any* encryption algorithm, which is why evaluating it is > difficult. This protocol is not using ECIES. > >> >>> >>>> >>>> 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. > > How does using TLS avoid the need to protect against DoS from sending > lots of Client Hellos? It doesn't. However, dealing with a bogus ClientHello takes significantly less work than dealing with the possible client messages in this protocol. > Also, the size of data encrypted with ECIES > doesn't affect the runtime. This protocol is not using ECIES. --Paul Hoffman _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
