<div dir="ltr"><div class="gmail_extra">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. </div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">So my list of preferred ciphers is fairly short, starting in 2000 when the export control laws were abandoned:</div><div class="gmail_extra"><br></div><div class="gmail_extra">2000 Necessary: RSA1024, SHA-1, RC4</div><div class="gmail_extra">2001 Preferred: RSA2048, SHA-2-256, AES-128</div><div class="gmail_extra">2010 Preferred: RSA2048, SHA2-512, AES-256 </div><div class="gmail_extra"><br></div><div class="gmail_extra">201x Preferred: IETF-EC-448, SHA2-512, AES-256 </div><div class="gmail_extra"><br></div><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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?</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Vendors have to learn that you don't wait till SHA-1 is considered vulnerable to start shipping the replacement.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">The ECC thing is a little different because the situation there has been complicated by too many specifications and too few actual standards.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div>