[Cryptography] FREAK attack

[Phillip Hallam-Baker]

I think the question is still not very useful. At each moment in time there
was a preferred algorithm for security and a necessary algorithm for
interop.

Due to poor design in the TLS upgrade mechanism, the transition time from
one to the other is about ten years. And what makes things worse is that
the browser folk have historically taken too long to deploy new algorithms,
then when the old ones have looked ropey they have made a great show of
rushing to the exit.

So my list of preferred ciphers is fairly short, starting in 2000 when the
export control laws were abandoned:

2000 Necessary: RSA1024, SHA-1, RC4
2001 Preferred: RSA2048, SHA-2-256, AES-128
2010 Preferred: RSA2048, SHA2-512, AES-256

201x Preferred: IETF-EC-448, SHA2-512, AES-256

Curve 25519 is acceptable for perfect forward secrecy but only with some
changes to the key exchange so the session keys are generated from the
WF128 and WF256 keys and not just the weaker one.

Now if we get into modes, then we can discuss HMAC versus AES MAC modes.
But I don't think the above would have been unreasonable.


I would like to see us clean up house for 201x and kill off the zoo of
legacy ciphers. Every one of those ciphers is a potential weak algorithm.
At each time we should have exactly one necessary algorithm and one
preferred.

Vendors should commit to a ten year service life for any crypto algorithm
that starts to expire only when they ship the replacement. In the case of
SHA-1 that was Service Pack 3 in 2008. So guess where the blame for the
phase out of SHA-1 taking so long should really belong?

This is not an argument for staying with SHA-1, rather it is an argument
that Microsoft should pull its finger out and start shipping SHA-3 now.
Because otherwise we are going to be going through the whole SHA-1
transition again in 2025 or so.

Vendors have to learn that you don't wait till SHA-1 is considered
vulnerable to start shipping the replacement.


The ECC thing is a little different because the situation there has been
complicated by too many specifications and too few actual standards.

All in all, this would be a good time to checkpoint the TLS stack and
declare a TLS/2 that kills the legacy cruft and starts from a solid
baseline. So no ocsp stapling option, stapling is mandatory, instead of 200
cipher suites reduce it to one mandatory to implement plus one backup and
then push all the rest of the crud out to optional proprietary extensions.
Make PFS and SNI required, introduce a mechanism to allow the handshake to
be encrypted under temporary keys passed in the DNS. Etc etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150307/c89534e4/attachment.html>