-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 2013-09-09 at 23:14 +0200, Hanno Böck wrote: > Also, DHE should only be considered secure with a large enough modulus > (>=2048 bit). Apache hard-fixes this to 1024 bit and it's not > configurable. So there even can be made an argument that ECDHE is more > secure - it doesn't have a widely deployed webserver using it in an > insecure way.
Bear in mind that TLS does not include D-H parameter size negotiation and various deployed clients and servers have under-documented fixed lower and upper bounds on the sizes. When those bounds are breached, what tends to happen is that TLS negotiation fails. At that point, the common approaches seen today are to throw up an error message (site down) or fallback to cleartext, *not* to disable the D-H suites and try TLS again. When I recoded Exim's GnuTLS integration, I originally made the D-H parameter generation just ask GnuTLS what sizes I should feed it for "NORMAL", in an attempt to get Exim out of the policy business and to trust the crypto libraries. I discovered the hard way that this value was higher than the upper-bound of the NSS crypto library, so that change made Thunderbird unable to talk to those release candidates of Exim. I had to write new security-parameter handling code during the RC series to work around this interoperability issue. The NSS upper limit was 2236 bits. Meanwhile, I discovered in the past week or so that prior to Exim 4.80 (when I redid the integration), Debian were patching the Exim code so that on Debian Exim installs the configured minimum acceptable size of D-H parameters was 2048 bits. Most sites were probably configuring 1024, or using Debian, so we had a source of real-world TLS breakage in mail-systems. Fortunately, that affects TLS-as-a-client from an MTA, where there's no trustworthy concept of remote identity yet (but DANE is changing that) so no host identity to verify, so the TLS between mail-servers that haven't configured stronger policy out-of-band is only protection against passive sniffing, at best. If folks are going to seriously start looking at how TLS can be improved in ways which make it less likely for systems to fail catastrophically, then *some* kind of D-H size limit negotiation, with clients able to decide to avoid D-H (if that's otherwise acceptable to policy) is pretty much required if the parameter sizes are ever to be changed to more useful values in real-world deployments. Apache are being conservative, but not without reason. - -Phil -----BEGIN PGP SIGNATURE----- iEUEAREDAAYFAlIug94ACgkQQDBDFTkDY384lQCgiuzP2Huj8e0dnvCPyByrBSZF jkAAkgL/CydbMoeFe3CaG2yuxmDk9ew= =8xFI -----END PGP SIGNATURE----- _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
