On Wed, Jul 4, 2018 at 11:15 AM David Benjamin <david...@chromium.org> wrote:
> On Wed, Jul 4, 2018 at 4:41 AM Nikos Mavrogiannopoulos <n...@redhat.com> > wrote: > >> On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote: >> > On Wed, Jul 04, 2018 at 07:57:41AM +0000, Peter Gutmann wrote: >> > > Ilari Liusvaara <ilariliusva...@welho.com> writes: >> > > >> > > > More serious problem is servers returning too small modulus due >> > > > lack of >> > > > negotiation. Which was the reason why Chrome disabled DHE. >> > > >> > > Why not reject the handshake if the modulus is too small, rather >> > > than >> > > disabling all DHE suites on the off chance that the server returns >> > > a value you >> > > don't like? >> > >> > Chrome initially did that. It caused quite a lot of bad feedback from >> > owners of various bad embedded stuff. The thread on relevant forums >> > was >> > quite something. Hundreds of messages blaming Google for breaking >> > stuff. >> >> We had similar experience when we required a minimum of 2048-bit >> modulus for all TLS connections in Fedora 28 beta irrespective of back- >> end lib. It broke connections to VPN servers and web internal web sites >> and we had to revert the change. The DHE ciphersuites under TLS1.2 seem >> doomed and rfc7919 couldn't save them. >> > > Indeed. 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. > See here for details: > Oops, that sentence should have read: "At the time of removal, 95% of DHE negotiations made by Chrome used a 1024-bit *group*." That is, were we to have enforced a 2048-bit minimum, 95% of DHE connections would have broken. With 5% of it salvageable, the TLS DHE code points are not worth saving. > > https://groups.google.com/a/chromium.org/d/msg/blink-dev/ShRaCsYx4lk/46rD81AsBwAJ > > I should add to that link that the "draft specification which fixes the > negotiation problems", now rfc7919, did not fix the problem. This was > pointed out here, but never incorporated to the document: > https://www.ietf.org/mail-archive/web/tls/current/msg18697.html > > To the original email, it seems the second and third scenarios are > identical. Configuring ECDHE+ECDSA ciphers is a no-op if using an RSA > server key. The third and fourth scenarios are indeed unsurprising for a > browser that doesn't support DHE. You should instruct these folks to > configure ECDHE+RSA ciphers if they have RSA keys. Particularly in the > second scenario, it seems they're already implemented, just the server was > incorrectly configured to use the wrong ones. > > DHE at acceptable sizes is quite slow anyway, so their servers may well > appreciate the speed boost. (Indeed, I often see DHE disabled in server > deployments as otherwise the poor servers would melt.) >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
