I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral: - The construction is broken. The leak itself in the Raccoon attack comes from TLS 1.2 removing leading zeros. We can't change the meaning of the existing code points, so any fix there would involve dropping them.
- It lacks group negotiation, which makes it very difficult to migrate away from small groups. At least in the web, it's already no longer supported by most implementations. https://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ https://bugzilla.mozilla.org/show_bug.cgi?id=1496639 https://weakdh.org/ On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle <cbartle891= 40icloud....@dmarc.ietf.org> wrote: > Agreed. I'll change the title to reflect that. > > > On Mar 8, 2021, at 7:33 AM, Martin Thomson <m...@lowentropy.net> wrote: > > > > Well overdue. We should do this. > > > > The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to > match the document content. I only see static or semi-static DH and ECDH > key exchange being deprecated (in the document as non-ephemeral). > > > > _______________________________________________ > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
