> On 11 Jul 2017, at 23:54, Christian Huitema <huit...@huitema.net> wrote: > > On 7/11/2017 1:31 PM, Stephen Farrell wrote: > >> PS: There are also genuine performance reasons why the same >> DH public might be re-used in some cases, so there would be >> false positives in a survey to consider as well. > > Well, yes. The classic argument is performance. Saving the cost of > exponentiation, computing G^X once for many session instead of once per > session. But you reap most of the benefits of that optimization with a > fairly small number of repetitions. Performance alone is not a good > reason to use the key over extended period, not to share the exact same > key between all servers in a farm. The fact is that wide reuse of the > same (EC)DH private key does compromise the security of TLS -- including > an obvious issue with forward secrecy.
I don’t think the number of times (within reason) a key is used matters that much. It only matters whether or not it is exportable. If a server implementations generates a fresh key for every session and then stores it in a database that maps public key to private key, then that database can trivially be used to decrypt all traffic. Conversely, an implementation could generate a key in memory and use it until reboot and as long as it’s not exported, nothing happens. I once implemented an ECDHE TLS server with an in-memory key that was rotated every 10 seconds. Since it was never written to disk (or even paged out) this practice did not compromise forward secrecy. The draft also recommends rotating the keys, but I guess that would be far less often than once every 10 seconds. But that is not the crucial difference. The crucial difference is that these keys get exported. Note, however, that the reason RSA ciphersuites were deprecated is that we are afraid that a stolen or coerced private key will compromise past sessions. If the session between us is recorded today and someone steals or demands my private key tomorrow, than they can decrypt our conversation from today. This is not the case in (EC)DHE ciphersuites in TLS 1.2 or 1.3. Any session that happens before this mechanism is turned on, is safe. Sessions can only be compromised after the server has enabled this feature, which is equivalent to handing over the RSA private key in RSA ciphersuites. That is not the forward secrecy issue that we wanted to solve by removing RSA ciphersuites. If one of the parties to a conversation cooperates with the wiretap, this isn’t an attack. Yoav
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
