Re: [TLS] Security today

[Mike <mike-list at pobox.com>]

> RSA labs' estimate seems a little pessimistic to me, as there has been a 
> 64-bit attack on SHA-1 for 2 years and even the original researchers 
> haven't got the computing resources to mount it. Sure, the NSA might be 
> able to do it, but not your average hacker, competitor or 
> moderately-sized botnet.  Given that, I don't see how we scale to 
> 80-bits in two years.

Even if it's 10 years or 20, why have such a small security margin?
Plus I believe that part of the lifetime estimate takes into account
the expected advances in factoring methods.

Put another way, if someone came to you and said they needed to
protect millions of transactions worth billions of dollars, would
you suggest 1024-bit RSA with RC4/MD5?  That's the reality we live
in today.

> Still, Amazon does not make its own certificates. It buys them from 
> Verisign or some other commercial CA. That vendor sells them the 
> 1024-bit RSA certificate, and nearly every web server certificate I've 
> ever seen is 1024-bit (I did see once a 1000-bit key on some site - who 
> needs powers of two, anyway?)  I don't know how the negotiation between 
> Amazon and Verisign goes, but from both parties' points of view, this 
> would require Amazon to use more computing resources (half a second is 
> cheap to you, but expensive for a web server - they care), or IOW 
> upgrade their server farm. A moderate expense for zero perceived 
> security benefits - it won't stop any attacks.

The problem is that Amazon (and I'm not picking on Amazon, just using
them as an example) is making the decision that my privacy is not as
important as pumping transactions through.  As a customer, I don't
have any way to say that I want them to do better.  There are no
parameters in TLS whereby the client can specify minimum acceptable
key lengths, for example.  The expensive (to Amazon) half second they
save by using a small RSA key is expensive to me in that my financial
information is not as well protected as I want - I care.  I'll gladly
pay 5 cents security infrastructure tax to Amazon for every transaction
I complete using better security.

This touches on a point I made months ago that it would be easy to
add an extension to TLS whereby a client could specify minimum key
lengths.  It was rejected by many who said it "would only provide a
false sense of security."  Well I never believed them, and now that
I've read Practical Cryptography by Schneier and Ferguson, and see
that in the key exchange protocol that they develop the very first
thing Alice sends to Bob is her minimum key length requirement, I
know that it is not a stupid idea!

> Nor can browser makers enforce minimal security - you don't want to make 
> a browser that won't work with Amazon.

No, but if TLS supported a mechanism for the client to specify some
of the security parameters (minimum RSA key size, DH p and q, etc.),
then their systems could use the less secure keys by default and
only pull out the big guns when someone explicitly asks for them.

> I don't think the IETF is the right body for a document such as you 
> propose. The admin at Amazon does not read the new RFC list to check 
> whether their certificate is still "good enough". I'm not sure what the 
> right body is, NIST is probably the one for the US, but even they tend 
> to make recommendations only for government bodies.

Do you really want to get the government involved?  Amazon's admin
may not read the latest RFC's, but probably Verisign's does, and
when Amazon's certificate expires, they can be enticed to upgrade
to a larger key, and even pointed to the RFC which would help them
choose better cipher suites (e.g. DHE_RSA_XX).

Mike
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls