Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

Great, sounds good to me then.

> On Mar 8, 2021, at 11:24 AM, David Benjamin <davidben@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 <cbartle891@icloud.com <mailto:cbartle891@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 <mt@lowentropy.net <mailto:mt@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.com@dmarc.ietf.org <mailto:40icloud.com@dmarc.ietf.org>> wrote:
> >>> Agreed. I'll change the title to reflect that.
> >>> 
> >>>> On Mar 8, 2021, at 7:33 AM, Martin Thomson <mt@lowentropy.net <mailto:mt@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>
> 