Re: [cryptography] DKIM: Who cares?
On 2012-10-26 2:44 AM, Ben Laurie wrote: As someone who sees the effects of actually using DKIM, I can but roll my eyes and shrug. In short, it turns out to be a pretty bad idea to hard fail on DKIM because it totally doesn't work with mailing lists. Which makes it pretty useless, key size cockups or no. Why did the authors of DKIM not deal with this problem? Long ago I posted on the DKIM mailing list raising a bunch of issues. I was very briefly told all those issues were out scope, and I posted no more. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DKIM: Who cares?
John Levine jo...@iecc.com writes: Hmmn. Is there some point to speculating about the behavior of mail systems about which you know nothing? Absolutely. We have a system design to perform a certain function (and, unfortunately, mis-marketed as being a solution to a rather different problem, but that's the marketers' fault and not the DKIM designers) that was deployed using a fatally flawed security config. I'd like to know why: - It probably wasn't an accidental mis-config, because it's unlikely that a pile of major organisations would all make the same config mistake. Look at SSL, the exact same organisations have no problem using strong SSL keys, but the same thing with DKIM uses weak keys. (Unfortunately Wired never said what percentage of DKIM users that they sampled exhibited this problem, so we don't know if their sample represented, say, 80% of DKIM users or 20% of DKIM users). - It's highly unlikely that all the organisations got together and said let's all agree to use really weak keys. That means there was probably some business, legal, or social reason why this occurred. Social seems unlikely, I can't imagine a legal reason, so I'm assuming there was some business-case issue that DKIM overlooked. The point is that a security mechanism was deployed on a large scale in a very insecure manner and we have no idea why, which means that we can't address the problem to ensure that it won't occur again. I'd like to find out what caused this, not to lay blame, but to understand what the issue was and to make sure that it won't come back to bite us again in future deployments. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DKIM makes Wired
Dave Crocker dcroc...@bbiw.net writes: In summary, it turns out that what seems like half the world's DKIM users are using toy keys as short as 384 bits. Since neither Wired nor CERT cited anyone's using 384-bit DKIM keys, I don't know where this assertion comes from. Harris found three classes of key lengths used by vulnerable domains . 384 bits, 512 bits, and 768 bits. .A 384-bit key I can factor on my laptop in 24 hours,. he says. .The 512-bit keys I can factor in about 72 hours using Amazon Web Services for $75. And I did do a number of those. Then there are the 768-bit keys. Those are not factorable by a normal person like me with my resources alone. But the government of Iran probably could, or a large group with sufficient computing resources could pull it off.. - How a Google Headhunter.s E-Mail Unraveled a Massive Net Security Hole, Kim Zetter, Wired magazine. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DKIM: Who cares?
On 26/10/12 20:11 PM, Peter Gutmann wrote: John Levine jo...@iecc.com writes: Hmmn. Is there some point to speculating about the behavior of mail systems about which you know nothing? Absolutely. We have a system design to perform a certain function (and, unfortunately, mis-marketed as being a solution to a rather different problem, but that's the marketers' fault and not the DKIM designers) that was deployed using a fatally flawed security config. I'd like to know why: - It probably wasn't an accidental mis-config, because it's unlikely that a pile of major organisations would all make the same config mistake. Look at SSL, the exact same organisations have no problem using strong SSL keys, but the same thing with DKIM uses weak keys. (Unfortunately Wired never said what percentage of DKIM users that they sampled exhibited this problem, so we don't know if their sample represented, say, 80% of DKIM users or 20% of DKIM users). - It's highly unlikely that all the organisations got together and said let's all agree to use really weak keys. That means there was probably some business, legal, or social reason why this occurred. With a nod to John, I would speculate entirely that this was caused by two factors: 1. that the process of integrating the DKIM into real world mail systems was much harder than expected, and long cycle times and hard work were needed. In the end people did what they could to make it work, coz it ran over-budget and under-comfort. 2. the early testing prototype kits were set up to generate keys and throw them away, as each test happens. Sometimes thousands of times a day. In such an environment, you don't want to waste a few seconds generating 1k keys, so the developers would have found they could speed things up by setting the test key size at 384, etc. Combine those two together and you'd find that once it was up and running, there would be a lot of temptation to work on the higher layer issues, or other issues, and not touch the underlying code. Don't fix what ain't broken. As I say - entirely speculation. Social seems unlikely, I can't imagine a legal reason, so I'm assuming there was some business-case issue that DKIM overlooked. I'd call it the sad reality of software deployment. It's a consequence of the golden rule of crypto - it has to deliver something working, before it ever gets to deliver that securely. IOW, a working product with toy crypto is still a working product; military grade crypto without a product is nothing. The point is that a security mechanism was deployed on a large scale in a very insecure manner and we have no idea why, which means that we can't address the problem to ensure that it won't occur again. I'd like to find out what caused this, not to lay blame, but to understand what the issue was and to make sure that it won't come back to bite us again in future deployments. One of the good thing about the crypto industry is that there are so many great failures to learn from. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DKIM: Who cares?
Peter Gutmann wrote: John Levine jo...@iecc.com writes: Is there some point to speculating ...? Absolutely. ... ... so I'm assuming there was some business-case issue ... ... a security mechanism was deployed on a large scale ... Let me speculate a moment. The 384 bits keys are much more efficient than 768+ keys (see HIP specifications first version which had a 384 bits DH prime for low-end environments). The business case is to avoid upgrading the e-mail servers merely because you turn on DKIM (hitting a CPU horsepower limit). Keep in mind that the RSA vs DSA spreads of CPU load between signer and verifier are reversed (RSA signature is more CPU-intensive, DSA verification is more CPU-intensive). Regards, -- - Thierry Moreau ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DKIM: Who cares?
On 2012-10-26 7:11 PM, Peter Gutmann wrote: I'd like to find out what caused this, not to lay blame, but to understand what the issue was and to make sure that it won't come back to bite us again in future deployments. My own experience, not necessarily typical and representative, is that it is difficult to have this sort of conversation with DKIM people, which if typical and representative would itself explain the cause. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Just how bad is OpenSSL ?
On Fri, Oct 26, 2012 at 06:29:47PM +, John Case wrote: So, given what is in the stanford report and then reading this rant about openssl, I am wondering just how bad openssl is ? I've never had to implement it or code with it, so I really have no idea. How long has it been understood that it's a mess (if it is indeed a mess) ? How dangerous is it ? It looks like the rant was published in 2009 Bad is such a subjective measurement. OpenSSL is very very hard for a non-expert to code against. It's hard to figure out what interfaces you should use, what interfaces are well tested, what interfaces are known to be unsafe, and what interfaces are buggy but can be used safely with careful coding. It's fairly easy to accidentally disable security critical codepaths in the process of iterative hmm that doesn't quite work, the docs are unclear, maybe this is a bug in my code or maybe a bug in OpenSSL? that is a normal part of software development. If you need to implement anything even slightly different from what was expected by the authors. The source code is mostly written to the OpenSSL coding standards, which are seriously different from any other coding standard I've seen (it's not Linux/KR, nor GNU, nor Microsoft, nor Sun/Oracle). Nonconformance with the coding standards in later patches is very common, so it's a mishmash of indentation standards on top of that. Naming conventions sometimes indicate that functions are strictly internal and should not be used by applications, but sometimes you have to use an internal API to get a necessary result and other times there are clearly internal APIs in the public namespace. I could go on. Overall, I would say that yes, OpenSSL is a huge mess for application developers. In that sense, it's very bad. On the other hand, it's the most thoroughly reviewed open source crypto implementation, and hasn't had very many security bugs found in the library per se. Its performance is fairly good. In that sense it's still the best option for some use cases. -andy ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DKIM: Who cares?
On Fri, Oct 26, 2012 at 2:27 AM, ianG i...@iang.org wrote: - It probably wasn't an accidental mis-config, because it's unlikely that a pile of major organisations would all make the same config mistake. Look at SSL, the exact same organisations have no problem using strong SSL keys, but the same thing with DKIM uses weak keys. Tools like Ivan Ristic's SSL Labs (https://www.ssllabs.com/) have done wonders for those wishing to make sure they have configured their HTTPS webservers correctly. You'll notice that similarly easy to use tools for other systems employing cryptography aren't what I'd call abundant. That means there was probably some business, legal, or social reason why this occurred. I expect initially, yes. Afterwards though I think a lack of easy to use tooling and monitoring tools is more to blame than anything. In the HTTPS world it is almost always the case that the organization that generates and manages the keys also manages/runs the webserver. In the email world you'll find that with the amount of outsourcing to ESPs the same thing isn't true. This makes DKIM more operationally complex than HTTPS. Not unbearably mind you, but definitely more complex. - Andy ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] DKIM: Who cares?
On 10/24/12 9:18 PM, Jon Callas wrote: Note the weasel-words long-lived. I think that the people caught out in this were risking things -- but let's also note that the length of exposure is the TTL of the DNS entries. I wouldn't characterize those as weasel-words, but rather that they were intentionally vague given the computational advances that can be expected during the lifetime of an IETF specification. John Graham observed this problem in mid-2010: http://blog.jgc.org/2010/06/facebooks-dkim-rsa-key-should-be.html and I did a survey of key lengths used by known signing domains at the time: http://blogs.cisco.com/security/key_lengths_for_dkim_signatures/ It would be interesting to see if the distribution has changed since then, but unfortunately I don't have access to that info any more. -Jim (another of the authors) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
