On Apr 1, 2014, at 7:37 PM, Olafur Gudmundsson <o...@ogud.com> wrote:
Pardon my language, but you are repeating the same bogus performance arguments that have hurt crypto for years. Having heard the same thing, over and over and over again, over the better part of a decade and change, it really does get to me. Symmetric key is effectively free on a modern computer (even when AES first came out you could do nearly a gigabit on a single core. Try getting a gigabit of I/O into or out of a circa 2001 PC), and even slow-old RSA, especially RSA validation, is close enough to free for practical purposes. And when you do have big load on a server serving many clients in the very rare case where the crypto IS the critical bottleneck, this is an obscenely parallel task... >> There is far far far too much worrying about "performance" of crypto, in >> cases like this where the performance just doesn't matter! >> > > disagree strongly, you are only looking at a part of the whole picture. > Verification adds resolution latency + verification adds extra queries which > is more latency > latency == un-happy eye-balls. You are talking about 50 microseconds of additional latency for using a real key length instead of 1024b lengths. Not milliseconds. Microseconds. 3e8 m/s * 1e-6s/us is 300m/us. So thats 15 kilometers of network travel if you remove all switches and lay down a vacuum cable. And remember, its not on the critical path except for the final validation, because you can use glue before it validates to do your lookups and validate the upper pieces of the hierarchy while waiting for the lower pieces to arrive, and well, its going to take a lot longer than 50 microseconds for that data to arrive. I don't see HFT systems doing DNSSEC validation... >> Yes, you can only do 18K verifies per CPU per second for 2048b keys. Cry me >> a river. Bite the bullet, go to 2048 bits NOW, especially since the servers >> do NOT have resistance to roll-back-the-clock attacks. > > Why not go to a good ECC instead ? (not sure which one, but not P256 or P384) > > 18K answers/second ==> is a fraction of what larger resolver servers do today > during peak times, yes not all answers need validation. > BUT you need to take into account that in some cases there is going to be > lots of redundancy in verification in large resolver clusters, thus > if your query stream hits 5 different hosts all of them may end up doing > almost 5x of the work, thus adding servers does not scale. > Yes people can create any cast clusters in depth where only the front end > ones do verification and the back end ones only answer queries, but > that has different implications. If the crypto is too much time in your cluster resolver, hash(name) to find cluster node that already has the answer. These have known, off the shelf solutions in the unlikely event that such a key length jump makes a difference. > Remember it is not average load that matters it is peak load, even if the > peak for 30 minutes on one day of the year. And even in that universal deployment case, of 10x the load of the average case, that is a whopping 10 CPU cores to do the crypto for a 1B lookup/day case. Thats less than a single server these days. 1B uncached lookups is a lot. This is a big number for things that are largely driven by human processes and which (even in the nightmare that is CDNs and 10s TTLs), cache, and which ISPs distribute close to the end user to save latency. Oh, and unless the CDN is doing dynamic signing, the RRSIG TTLs are much longer, so the crypto operations cache for a lot longer TTL. > Over the years I have been saying use keys that are appropriate, thus for > someone like Paypal it makes sense to have strong keys, > but for my private domain does it matter what key size I use? > I do not buy the theory that one size fits all model for crypto, people > should not use unsafe crypto, but the one size fits all is not the > right answer, just like not every zone needs a KSK and ZSK split. ( I use > single 1280 bit RSA key with NSEC) > A real world analogy is that not everyone needs the same kind of car, some > people need big cars, others small ones or even no car. But at the same time, we mandate certain crash resistance. RSA keys of less than 2048b should be deprecated, and DNSSEC software MUST NOT generate them. We do not sell cars with bodies made of silly putty and airbags made from party balloons, we SHOULD NOT deploy software with known unsafe key lengths. > Furthermore using larger keys than your parents is non-sensical as that moves > the cheap point of key cracking attack. And why do you think I'm so pissed at the root, and com, and everyone else using 1024b keys? Thats a joke, a bad one, and it needs to be fixed, and it needs to be fixed to be a real value, and real value, based on real cryptographers recommendations dating back the better part of a decade is 2048b. >> In a major cluster validating recursive resolver, like what Comcast runs >> with Nominum or Google uses with Public DNS, the question is not how many >> verifies it can do per second per CPU core, but how many verifies it needs >> to do per second per CPU core. > > I have no doubt that CPU's can keep up but the point I was trying to make is > increasing the key sizes by this big jump > ==> invalidates peoples assumptions on what the load is going to be in the > near term. How many resolvers are currently spending more than 10% of CPU doing DNSSEC validation right now? Any above 1%? >> And at the same time, this is a problem we already know how to parallelize, >> and which is obscenely parallel, and which also caches… > > Do we? Some high performance DNS software is still un-treaded, many resolvers > are run in VM's with low number of cores > exported to the VM. Who is running a major centralized ISP (1M+ customers on a single resolver instance, 1B+ external lookups/day) on a un-threaded, low powered system for DNS yet doing DNSSEC validation? The systems you are talking about are in the 100M external lookup range or less, and in that case the crypto really doesn't matter to the performance. Oh, and they aren't validating anyway, so who cares? >> Lets assume a typical day of 1 billion external lookups for a major ISP >> centralized resolver, and that all are verified. Thats less 1 CPU core-day >> to validate every DNSSEC lookup that day at 2048b keys. > > 1B is low due to low TTL's and synthetic names used for transactions, and as > I said before it is peak load that matters not average. > DNSSEC processing is just a part of the whole processing model. 1B external lookups is a number taken from when I was looking at SIE data (which captures the queries from the participating recursive resolvers) about a year ago to detect covert channels. It was ~2B/day lookups in the data set, but there were multiple major cluster resolvers belonging to a single top 10 US ISP which dominated that dataset. Even assuming peak load 10x average (an unrealistic amount of peakiness if you've ever looked at network traffic graphs), and every answer has to validate once (yes, you may have a few more, but in practice this caches as well, since all 1B lookups are not going to be to 1B different domains...), thats still just 10 CPU cores. The nearly 2-year-old mac mini on my desktop is a quad core. If your billion lookup a day DNS resolver is validating DNSSEC, everything is signed, yet you can't afford to run on a single modern dual-CPU oct-core system, you get no sympathy from me. >> And yeah, DNS is peaky, but that's also why this task is being run on a >> cluster already, and each cluster node has a lot of CPUs. > > that costs money, and effort to operate. Effort? How? The assumption is you are already going through the hassle of validation. Money? You're talking peanuts. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
