I guess it's a question of what the goal of this draft is. I don't particularly care as long as it's self-consistent. :-)
We've got the title, "FFDH(E)", which would suggest targeting TLS_DH_*, TLS_DHE_*, and even NamedGroup.ffdhe*, and not anything around ECDH(E). We've got the contents, which are targeting non-PFS flows, EC or FF. That is, TLS_DH_*, TLS_ECDH_*, and uses of (EC)DHE that aren't actually ephemeral. We've got the Raccoon citation, which would suggest[*] targeting TLS_DH_* and TLS_DHE_*, due to the buggy construction, and possibly also the non-PFS modes of both 1.3 FFDHE and 1.2/1.3 ECDHE because key reuse is more fragile. [*] From the conclusion of the paper: "The most straightforward mitigation against the attack is to remove support for TLS-DH(E) entirely, as most major client implementations have already stopped supporting them" On Mon, Mar 8, 2021 at 2:06 PM Carrick Bartle <cbartle...@icloud.com> wrote: > I'm not opposed to expanding the scope of this document to include > deprecating DHE. Is there a major advantage to that being its own draft? > > > > On Mar 8, 2021, at 10:09 AM, Martin Thomson <m...@lowentropy.net> wrote: > > > > One thing at a time? > > > > On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote: > >> 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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
