Great, sounds good to me then. > On Mar 8, 2021, at 11:24 AM, David Benjamin <david...@chromium.org> wrote: > > 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 > <mailto: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 > > <mailto: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://groups.google.com/a/chromium.org/g/blink-dev/c/AAdv838-koo/m/bJv17voIBAAJ> > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1496639 > >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1496639> > >> https://weakdh.org/ <https://weakdh.org/> > >> > >> On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle > >> <cbartle891=40icloud....@dmarc.ietf.org > >> <mailto: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 > >>>> <mailto: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 <mailto:TLS@ietf.org> > >>>> https://www.ietf.org/mailman/listinfo/tls > >>>> <https://www.ietf.org/mailman/listinfo/tls> > >>> > >>> _______________________________________________ > >>> TLS mailing list > >>> TLS@ietf.org <mailto:TLS@ietf.org> > >>> https://www.ietf.org/mailman/listinfo/tls > >>> <https://www.ietf.org/mailman/listinfo/tls> > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org <mailto:TLS@ietf.org> > > https://www.ietf.org/mailman/listinfo/tls > > <https://www.ietf.org/mailman/listinfo/tls> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
