Hi David, My understanding is that we're only discussing deprecating DHE for 1.2. 1.3 is out of scope for this document.
Carrick On Tue, Dec 13, 2022 at 10:06 AM David Benjamin <david...@chromium.org> wrote: > Small clarification question: is this about just FFDHE in TLS 1.2, i.e. > the TLS_DHE_* cipher suites, or also the ffdhe* NamedGroup values as used > in TLS 1.3? > > I support deprecating the TLS_DHE_* ciphers in TLS 1.2. Indeed, we removed > them from Chrome back in 2016 > <https://groups.google.com/a/chromium.org/g/blink-dev/c/ShRaCsYx4lk/m/46rD81AsBwAJ> > and > from BoringSSL not too long afterwards. > > The DHE construction in TLS 1.2 was flawed in failing to negotiate groups. > The Logjam <https://weakdh.org/> attack should not have mattered and > instead was very difficult to mitigate without just dropping DHE entirely. > The lack of negotiation also exacerbates the DoS risks with DHE in much the > same way. It is also why the client text in the current draft > <https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-01.html#section-3-2.2> > ("The group size is at least 2048 bits"), and the previous one > <https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-00.html#section-3-2.2> > ("The group is one of the following well-known groups described in > [RFC7919]: ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192") are not > easily implementable. By the time we've gotten an unsatisfying group from > the server, it's too late to change parameters. Trying with a new > connection and different parameters is also problematic because of > downgrade attacks. A correct scheme would have been defined to only use > NamedGroup values, and so the server could pick another option if no groups > were in common. > > RFC 7919 should have fixed this, but it too was flawed: it reused the > cipher suites before, making it impossible to filter out old servers. See > these discussions: > https://mailarchive.ietf.org/arch/msg/tls/I3hATzFWwkc2GZqt3hB8QX4c-CA/ > https://mailarchive.ietf.org/arch/msg/tls/DzazUXCUZDUpVgBPVHOwatb65dA/ > https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo/ > > Additionally, the shared secret drops leading zeros, which leaks a timing > side channel as a result. Secrets should be fixed-width. See > https://raccoon-attack.com/ and > https://github.com/tlswg/tls13-spec/pull/462 > > At this point, fixing all this with a protocol change no longer makes > sense. Any change we make now won't affect existing deployments. Any update > that picks up the protocol change may as well pick up TLS 1.3 with the ECDH > groups. Thus the best option is to just deprecate them, so deployments can > know this is not the direction to go. > > Of course, some deployments may have different needs. I'm sure there are > still corners of the world that still need to carry SSL 3.0 with RC4 > despite RFC 7465 and RFC 7568. For instance, during the meeting, we > discussed how opportunistic encryption needs are sometimes different, which > is already generically covered by RFC 7435 > <https://www.rfc-editor.org/rfc/rfc7435#section-3> ("OSS protocols may > employ more liberal settings than would be best practice [...]"). All that > is fine and does not conflict with deprecating. These modes do not meet the > overall standard expected for TLS modes, so this WG should communicate that. > > I'm somewhere between supportive and ambivalent on the ffdhe* NamedGroup > values in TLS 1.3. We do not expect to ever implement them in BoringSSL, > and their performance would be quite a DoS concern if we ever did. But that > construction is not as deeply flawed as the TLS 1.2 construction. > > 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
