Martin Rex <m...@sap.com> writes: >Cough, what? TLS_DHE_ was known to be a security disaster beyond fixing a >good decade ago (14-May-2007): > > https://www.ietf.org/mail-archive/web/tls/current/msg01647.html
That's not DHE that's the problem, it's the use of ridiculously short toy keys that were known to be insecure 20-25 years ago when they were mandated for export grade use. >but it needed a LOGJAM demonstration to have folks look at the crappy >implementations in the installed base. Sure, LOGJAM pointed it out, and spurred fixes (finally), just like FREAK did for RSA (and BEAST did, and POODLE did, and CRIME did, and BREACH did, and FLUFFYBUNNY did, and Heartbleed did, it always takes some attack with a cool name before people fix their code). I'm still waiting for a paper to point out that 512-bit DSA and secp160 are insecure, I assume the lack of public use of these is what's prevented that. The point is it has nothing to do with DHE, you've got exactly the same vulnerability with RSA-512, DH-512, DSA-512, Elgamal-512, and Mr-Not- Appearing-in-this-List-512. LOGJAM had two great contributions, firstly pointing out that there were a scary number of servers that still allowed toy keys, and secondly providing a baseline where, if you're worth less than several hundred million to several billion dollars to an attacker, DH-1024 is still OK (as long as it's not group2, that one's a bit too risky). >Probably most usage scenarios that still offer TLS_DHE today, provide less >security than with static-RSA 2048-bit. Sure, if you choose your DH key to be 512 bits and your RSA key to be 2048, you can make that claim. I'm going to choose my RSA key to be 128 bits and my DH key to be 16384 bits, in which case DH wins again. And by quite a margin, I must say. >How often does your SCADA devices (=servers) regenerate its DHE params? That's a question I can't answer in general because I've only seen the source code for a small number of vendor-specific embedded implementations (under various NDAs), but both from the code and from knowing the coding style used for these implementations, they'll do so on every connection because that's how the textbooks describe it. These implementations do just enough to connect to a client or server (some act as clients connecting to things like PLC control centres). They are the bare minimum needed to function. Cert processing is done with memcpy() of a pre-encoded blob. TLS extensions are encoded with memcpy() and decoded with memcmp(). You get the picture. No-one would even think of the possibility of cacheing DH parameters, let alone sit down and write the code for it. >Static RSA-2048 will always be better than DHE-1024. Since this will be exposing a private-key op with every decryption oracle and side channel known to research science directly to anything on the network (see the comment above on how these implementations are written), I'm going to disagree with you there. With DH you've admittedly still got the RSA sig, but that's buried behind/under so much other stuff I doubt it's exploitable. >Simply regenerate and roll your RSA keys&server cert if it makes you feel >good. Since that could involve a firmware reflash (with the new cert coded into the firmware), on a remote device that can never go offline, it's not likely to happen. In a previous message I mentioned an example of using DSA for TLS. This is because you can generate a DSA key in essentially zero memory with a single modexp, which completes before the watchdog times out and restarts the system. You can't do that with RSA in hard real-time. Also, there's no way to "roll the cert", it's baked in at the factory or when the device is deployed. Well, a reflash I guess, but then see above. >btw. which kind of "problematic pure-RSA" are you talking of? See above, exposing your private key via every kind of side channel and decryption oracle to a network attacker. >because of the illusion of PFS, which they create but do not offer. Maybe I shouldn't have mentioned PFS, I used that as an example because it was quicker than writing several paragraphs on why pure RSA is dangerous. PFS is actually more or less irrelevant for SCADA, it's something cryptographers care about but SCADA folks don't because pretty much all the traffic being carried is tactical, no-one's worried about an attacker being able to go back later and see that you sent a pilot-operated relief valve activation command two weeks ago in your non-PFS encrypted traffic. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls