David Benjamin <david...@chromium.org>​ writes: >The bad feedback was not even at a 2048-bit minimum, but a mere 1024-bit >minimum. (Chrome enabled far more DHE ciphers than others, so we encountered >a lot of this.) 2048-bit was completely hopeless. At the time of removal, 95% >of DHE negotiations made by Chrome used a 1024-bit minimum.
How does Google, rather than the people running the systems being connected to, know that 1024-bit DH isn't secure enough for a given environment? The majority of this stuff is running on isolated, private networks or inside VPN tunnels for which pretty much anything, including 512-bit keys, are fine. It's also somewhat disturbing that Chrome now walks straight past a perfectly good PFS DHE suite and instead goes to a problematic pure-RSA one instead. >You should instruct these folks to configure ECDHE+RSA ciphers if they have >RSA keys. The devices don't do ECDHE, and they probably never will (at least until the next upgrade cycle, which could take a decade or more), so there's nothing to configure. >rfc7919, did not fix the problem. This was pointed out here, but never >incorporated to the document: Yep. The issues were pointed out by several people before it was published, but got published anyway... with the result being that a number of implementations chose not to support it because of the problems that it causes. >Particularly in the second scenario, it seems they're already implemented, >just the server was incorrectly configured to use the wrong ones. That was in my testing, not using a PLC control centre or similar, in other words the actual devices being used in the field. Doing that would have required a firmware reload for each test, which is way too painful to think about. For "server incorrectly configured", see above, they were offering all the suites the firmware and hardware supported. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
