After a break of a few months I rejoined the DNSOP WG mail list. After the very first message I sent a complaint to the chairs over the tone and language. I feel I should send a note about that to the open list itself.
It’s not that I have a puritan tongue. It’s that such low-brow language, including the subject line’s obtuse reference to an obscene expression and finally to the out right vulgar expression in the thread call into doubt the level of professionalism of this WG. It’s hard to defend the work that results from a group that exhibits juvenile behavior. I realize that I am reacting to perhaps the writing of one person (perhaps, I never tried to verify the originator) and perhaps reacting to the interaction of a small group of individuals - even if some are well-intentioned here. But I think that it is up to the WG to defend it’s stature and not accommodate this low level of discourse. As to the matter at hand, I had been an operator of DNS services for about the past decade, designed the initial role out of DNSSEC in places, and ran a measurement experiment for a few years to quantify the choices. I found that there are two primary reasons why 1024 bits is used in zone signing keys. One - peer pressure. Most other operators start out with 1024 bits. I know of some cases where operators wanted to choose other sizes but were told to “follow the flock.” Two - it works. No one has ever demonstrated a failure of a 1024 bit key to provide as-expected protection. >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. 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. 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. It nets to this - cryptographers urge for longer lengths but can’t come up with a specific, clearly rational, recommendation. DNS operators want smaller, web performance wants quicker. Putting all that together, the smaller key size makes sense. In operations. 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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
