[cryptography] Diginotar Lessons Learned (long)

Ian G iang at iang.org
Sat Sep 10 18:09:27 EDT 2011



On 11/09/2011, at 3:22, Andy Steingruebl <andy at steingruebl.com> wrote:

> On Fri, Sep 9, 2011 at 6:22 PM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
> 
>> May I make the following modest proposal:
>> 
>>  A "fix" (of whatever form you want to try) is only regarded as valid if it
>>  leads to at least a 25% decrease in phishing, measured over the interval
>>  before and after its introduction.
> 
> We've had this discussion before.  Attackers will go wherever the
> attacks are easiest, and if we don't fix things we know are attackable
> (all/most of them) we're just pushing the problem around, not really
> making the bad guys jobs easier.
> 
> We still need to prioritize of course, and fix the things being
> exploited rather than just increasing key-lengths (the typical
> approach) but that doesn't mean that fixing things that aren't being
> exploited now, but we know can be exploited, is a waste of time.



The process of managing risks is to reduce the overall cost, not any one particular risk.  Each fix will cost, and typically this will cause losses that means other risks aren't fixed.

The canonical case here is that because SSL is too hard to use (because it fixes MITM so well :) it actually doesn't deploy as much as it should.

The consequence is that MITM is too easy because there isn't enough SSL in use, so there isn't attention put on the downgrade attack from phishing. Same with a whole slew of attacks against http, which are defeated by https.

Perverse :) every fix costs resources, which might be deployed on another fix.

> Right?

Hence, in general, anything that makes SSL easier to use pays more dividend than any exotic security fix such as v3 or renegotiation. hence the https-everywhere project, which aims to fix phishing by removing the need to ever downgrade. Also TLS/SNI.

Or, I agree with Peter, results count more than theory. Or, fixing usability typically dominates fixing security bigs.

Iang


More information about the cryptography mailing list