On Thursday, October 25, 2012 09:38:36 AM Thijs Kinkhorst wrote: > On Thu, October 25, 2012 07:18, Scott Kitterman wrote: > > Package: opendkim > > Version: 2.0.1+dfsg-1 > > Severity: grave > > Tags: security upstream > > Justification: user security hole > > > > See http://www.kb.cert.org/vuls/id/268267, VU#268267 > > > > opendkim in squeeze, wheezy, sid offers no method to prevent use of keys > > less than 1024 bits. This is added in the new upstream release, 2.6.8, > > that > > was released just for this issue. > > Thanks for your quick action on this. But is it really a user security > hole? The responsibility is with users not to use unsafe key sizes. GnuPG > works with small key sizes, I do not see that as a user security hole per > se. > > Of course this proactive measure can help to prevent mistakes, so if > possible it would be good if we could still get this into wheezy.
I agree that on the sending end this is mostly an operational issue, but on the receiving side this is different. Here's a description of the attack that the changes in opendkim 2.6.8 will prevent: http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-widespread/ With what's in Squeeze/Wheezy now, a Debian mail server would have validated the mail as well. With 2.6.8, the signature would have been ignored (in the default configuration) because the key size is too small. This is not something that can be dealt with operationally. Unlike GPG, where keys are trusted based on signatures and web of trust (and people can decline to sign bad keys), in DKIM keys are trusted based on their being published in the sending domain's DNS and there is no human in the loop. Scott K
signature.asc
Description: This is a digitally signed message part.
