> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Jakob Bohm > Sent: Thursday, December 07, 2017 01:44 > > > Actually in some of my code, I have found that the callback can > still be useful by examining the SSL session argument to > heuristically identify likely client side DH size capability and > thus choose between modernDH parameter sizes.
Interesting idea. We might look into doing something similar someday. > P.S. Forcing use of common DH parameters in TLS 1.3 would directly > make all TLS 1.3 implementations vulnerable to LogJam. That would > be absurd. That's what TLSv1.3 does, as of the latest I-D (and several previous revisions). Technically, it's not vulnerable to LogJam - LogJam is a downgrade attack, to a 512-bit "export" group, and the smallest group in RFC 7919 is 2048 bits. Using the same parameters across all implementations makes TLSv1.3 theoretically vulnerable to the WeakDH part of the LogJam/WeakDH attack class, but the presumption is that for even well-resourced adversaries a 2048-bit group is intractable. The WeakDH paper suggests breaking a 1024-bit group is feasible, but 2048 is obviously far more expensive. (The exact relationship isn't straightforward to determine, but it's exponential.) For the paranoid, RFC 7919 / TLSv1.3 give you groups up to 8192 bits. I am myself not entirely keen on this aspect of TLSv1.3, but this version of TLS has had much more cryptological analysis and engineering than any previous one. I'm sure this issue was discussed at length. I've seen more than one recommendation to use RFC 7919 groups, rather than arbitrary ones, even for older TLS versions. This is a change from the original WeakDH recommendations. (The "Imperfect Forward Secrecy" paper came out in October 2015, and RFC 7919 in August 2016.) -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
