The profanity is deliberate. The same discredited performance arguments have come up for a decade+. It gets very frustrating to see the same ignorance, again and again.
On Apr 2, 2014, at 6:30 AM, Edward Lewis <edlewis.subscri...@cox.net> wrote: >> From these two main reasons (and you’ll notice nothing about cryptographic >> strength in there) a third very import influence must be understood - the >> tools operators use more or less nudge operators to the 1024 bit size. >> Perhaps via the default settings or perhaps in the tutorials and >> documentation that is read. > > Why do operators seem to ignore the input of cryptographers? I can tell you > that from personal experience. Cryptographers, whenever given a straight > question on DNSSEC have failed to give straight answers. As is evident in > the thread, theoretical statements are made and the discussion will veer off > into recursive (really cache-protection) behaviors, but never wind up with a > result that is clearly presented and defended. In my personal experience, > when I recommended 1024 bits, it was after consulting cryptographic experts > who would just waffle on what size is needed and then relying on what we did > in workshops 15 years ago. Well, its because for the most part, cryptographers do seem to understand that DNSSEC is a bit of a joke when it comes to actually securing conventional DNS records. And the NIST crypto recommendations have existed for years. 1024b RSA was "deprecated in 2010, eliminate completely in 2013". There may be doubt in NIST now, but 2 years ago, to ignore the standard recommendations is foolish. > What does it matter from a security perspective? DNS messages are short > lived. It’s not like we are encrypting a novel to be kept secret for 100 > years. With zone signing keys lasting a month, 6 months, or so, and the > ability to disallow them fairly quickly, what’s the difference between this > so-called 80 or 112 bit strength difference? Yes, I understand the doomsday > scenario that someone might “guess” my private key and forge messages. But > an attack is not as simple as forging messages, it takes the ability to > inject them too. That can be done - but chaining all these things together > just makes the attack that much less prevalent. Do your resolvers have protection against "roll back the clock" attacks? If not, you do not "gain protection" from the short-lived (well, really, a few month, they don't roll the actual key every 2 weeks) nature of the ZSK for root, .com, etc. > Saving space and time does matter. Roughly half the operators I studied > would include a backup key on-line because “they could” with the shorted > length. And performance does matter - ask the web browser people. Amdahl's law seems to be something that computer science in general always seems to forget. The performance impact, both in size and cryptographic overhead, to shift to 2048b keys is negligible in almost all cases. And the step function in DNS cost, the "Internet can't do fragments" problem, doesn't really come into play at 2048b. > It nets to this - cryptographers urge for longer lengths but can’t come up > with a specific, clearly rational, recommendation. Yes they have. 2048b. > DNS operators want smaller, web performance wants quicker. Putting all that > together, the smaller key size makes sense. In operations. The real dirty secret. DNSSEC is actually useless for, well, DNS. A records and the like do not benefit from cryptographic protection against a MitM adversary, as that adversary can just as easily attack the final protocol. Thus the only actual use for DNSSEC is not protecting A records, but protecting cryptographic material and other similar operations: DANE is probably the best example to date, but there is also substantial utility in, e.g., email keys. DNSSEC is unique in that it is a PKI with constrained and enforced path of trust along existing business relationships. Building the root of this foundation on the sand of short keys, keys that we know that are well within range for nation-state adversaries, from the root and TLDs is a recipe to ensure that DNSSEC is, rightly, treated by the rest of the world as a pointless joke. > PS - Yes, some operators do use longer keys. Generally, those that do have > decent “excuses” (read: unusual use cases) and so they are not used in the > peer pressure arguments. And that does no good unless the upstream in the path of trust, starting at the root, actually use real length keys. The difference between 2^80 and 2^100 effort is huge. 2^80 is in range today of nation states, and near the range of academics. -- 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
