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
