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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
