> I certainly am, especially given that there are no security reasons driving it.
Could you describe your reasoning behind this statement? From my read, supporters of deprecation have made it pretty clear that the motivation behind deprecating DHE is security considerations: there is no way to securely negotiate it without introducing potential DoS issues. On Tue, Dec 13, 2022 at 8:14 PM Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > Maybe you are saying this decision is premature. > > > > I certainly am, especially given that there are no security reasons > driving it. > > > > Surely there is a limit to this reasoning, though. > > > > Of course. > > > > There is a MacOS 9 system right next to me, and it doesn't support > anything beyond SSL3. I would not expect the IETF to accommodate that > system. > > > > Correct. And I wouldn’t expect the IETF to accommodate whatever Windows 95 > used to support, if anybody still has it. But, as you said, there’s a limit > to this reasoning as well. > > > > So, can you explain your point a bit more? > > > > I think I’ve made my point already – there are devices that use FFDHE, > which remain secure (so far), and may require access by new <whatever>. > Thus, an RFC that would prohibit it, sounds, as you said yourself, > premature. > > > > I think "zero security reasons" sounds like something we should work out, > but arguments like "who cares for systems like SCADA" are a bit off the > mark. The IETF can't perpetually support systems that can't be upgraded, > because attacks always get better. > > > > I see a great distance between “perpetual” and “premature”. And SCADA is > just one area, which I brought up because it’s closer to me than, e.g., > browsers-and-websites realm. > > > > And stand by my opinion that deprecating a perfectly functional and secure > protocol (for reasons I consider frivolous at best) and ignore the likely > harm such deprecation would cause, is, er, “premature”. > > > > > > > > thanks, > > Rob > > > > > > On Tue, Dec 13, 2022 at 3:01 PM Blumenthal, Uri - 0553 - MITLL < > u...@ll.mit.edu> wrote: > > That sounds like deprecation to me (stop building new things this way...) > > > > Build new things that stop interoperating with old things? Does not sound > smart to me. > > > > Not to mention that there’s zero security reasons for this deprecation. > > > > I support deprecating all FFDHE cipher suites. The IETF should not > perpetually support systems that can't be upgraded. > > > > Yeah, who cares for systems like SCADA. Sure. > > > > > > On Tue, Dec 13, 2022 at 7:51 AM Blumenthal, Uri - 0553 - MITLL < > u...@ll.mit.edu> wrote: > > I do not support deprecation, because there will be deployed devices (IoT, > SCADA) that aren’t upgradable – and the new stuff will have to access them. > > > > I’ll spare the group my personal opinion about this draft. > > -- > > V/R, > > Uri > > > > > > *From: *TLS <tls-boun...@ietf.org> on behalf of Ira McDonald < > blueroofmu...@gmail.com> > *Date: *Tuesday, December 13, 2022 at 10:47 > *To: *Sean Turner <s...@sn3rd.com>, Ira McDonald <blueroofmu...@gmail.com> > *Cc: *TLS List <tls@ietf.org> > *Subject: *Re: [TLS] consensus call: deprecate all FFDHE cipher suites > > > > Hi, > > > > Yes - I support deprecating all FFDHE cipher suites including well-known > groups. > > > > Cheers, > > - Ira > > > > > > On Tue, Dec 13, 2022 at 9:46 AM Sean Turner <s...@sn3rd.com> wrote: > > During the tls@IETF 115 session topic covering > draft-ietd-tls-deprecate-obsolete-kex, the sense of the room was that there > was support to deprecate all FFDHE cipher suites including well-known > groups. This message starts the process to judge whether there is consensus > to deprecate all FFDHE cipher suites including those well-known groups. > Please indicate whether you do or do not support deprecation of FFDHE > cipher suites by 2359UTC on 6 January 2023. If do not support deprecation, > please indicate why. > > NOTE: We had an earlier consensus call on this topic when adopting > draft-ietd-tls-deprecate-obsolete-kex, but the results were inconclusive. > If necessary, we will start consensus calls on other issues in separate > threads. > > Cheers, > Chris, Joe, and Sean > _______________________________________________ > 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
