[cryptography] DKIM: Who cares?

ianG iang at iang.org
Fri Oct 26 05:27:26 EDT 2012


On 26/10/12 20:11 PM, Peter Gutmann wrote:
> John Levine <johnl at 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




More information about the cryptography mailing list