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. > 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 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. > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
