Chrome dropped TLS 1.2 DHE nearly five years ago now. I don't have data on the current DHE-to-RSA conversion, but I can tell you what it was then. When we put it under a fallback for measurement, only 2% of connections negotiated DHE. Of that 2%, 95% used 1024-bit DHE. That means we really only had 2% * 5% = 0.1% of connections that actually used it effectively. https://groups.google.com/a/chromium.org/g/security-dev/c/dYyhKHPnrI0/m/pNxx8vTKBAA
At 95% with no group negotiation, clearing DHE-1024 was implausible without a *dramatic* shift in the server population. Moreover, there is a TLS client with a *maximum* DHE group size of 1024-bit, so servers risked interop problems if they switched to larger group sizes. (To say nothing of DoS risks because DHE is pretty slow.) The code points are basically stuck. It's a pity we didn't have RFC7919 from the start, but anyone implementing it can already implement ECDHE and now TLS 1.3. It also doesn't help here because, by reusing the old TLS 1.2 DHE code points, it's not possible for a client to offer RFC7919 TLS 1.2 DHE without simultaneously offering legacy TLS 1.2 DHE. All those numbers were five years ago. ECDHE deployment has increased substantially, so DHE's value has only gone down. Looks like Firefox dropped it more recently, so perhaps they'll have more recent numbers. David On Mon, Mar 8, 2021 at 7:30 PM Andrei Popov <Andrei.Popov= 40microsoft....@dmarc.ietf.org> wrote: > Hi Brian, > > > > - Look at Windows Server 2012 and similar legacy products that are in > widespread use, which don't support any PFS cipher suites except FFDHE. > > Windows Server 2012/Windows 8 support both TLS_ECDHE_ECDSA and > TLS_ECDHE_RSA cipher suites: TLS Cipher Suites in Windows 8 - Win32 apps > | Microsoft Docs > <https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-8> > > > > Our telemetry shows extremely low usage of TLS_DHE cipher suites and I’m > in favor of deprecating them. > > > > Cheers, > > > > Andrei > > > > *From:* TLS <tls-boun...@ietf.org> *On Behalf Of * Brian Smith > *Sent:* Monday, March 8, 2021 4:13 PM > *To:* Martin Thomson <m...@lowentropy.net> > *Cc:* <tls@ietf.org> <tls@ietf.org> > *Subject:* [EXTERNAL] Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe > > > > It is sad that nobody is willing to discuss the obvious downsides of this > proposal as written, which should at least be mentioned in the security > considerations. Without discussing the downsides we're reducing engineering > to politics. If we discuss the downsides then we can substantially improve > the proposal. > > > > Deprecating FFDHE key exchange without deprecating RSA key exchange will > substantially increase the usage of RSA key exchange and thus make server > key compromise more dangerous. At a minimum, RSA key exchange should be > deprecated at the same time, in the same document. > > > > Look at Windows Server 2012 and similar legacy products that are in > widespread use, which don't support any PFS cipher suites except FFDHE. > Please deprecate RSA key exchange at the same time so that there is enough > motivation for vendors of these legacy products to add safe alternatives > and/or for users of these legacy implementations to upgrade to something > new that implements a safe alternative. (Note that Windows Server 2012 did > add a patch to enable increasing its FFDHE key size to safe sizes.) > > > > It would be useful for the browser vendors that recently dropped FFDHE > support to share their measurements for how much RSA key exchange usage > increased after their changes. That would help us quantify the real-world > impact of this change. > > > > RSA key exchange uses flawed and error-prone cryptography that is prone to > side channels as well, PKCS#1 encryption/decryption. Previous studies have > found widespread flaws in implementations that are (AFAICT) even more > easily exploitable than the Racoon attack is. > > > > It is easy to imagine a perfect implementation of RSA key exchange that > also perfectly protects the server's private key. It is unrealistic to > expect implementations to actually live up to that ideal. When RSA key > exchange is used, then a government that can effectively undo all the past > encryption of a server if it can force the server operator to disclose the > key, even for a perfect implementation of RSA key exchange. > > > > Deprecating RSA key exchange at the same time as FFDHE will encourage > adoption of newer products that also often support TLS 1.3. > > > > Without creating a new, correct, way to use FFDHE key exchange, we're left > with elliptic curve (ECDHE) key exchange as the only reasonable and > widely-implemented key exchange mechanism. > > > > Cheers, > > Brian > > (Speaking only for myself) > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
