It is, however, mentioned throughout the actual text of the document, assuming we're both looking at draft-ietf-tls-deprecate-obsolete-kex-01. I think the document describes its current change just fine. I asked only because I wasn't sure which the consensus call was about, since that isn't yet reflected in the document. (The document just says the group size must be at least 2048 bits in TLS 1.2, and then notes that TLS 1.3 satisfies that already. We're now talking here about deprecating the DHE ciphers altogether because, without negotiation, constraining group size isn't actually viable.)
It sounds like this consensus call was indeed just about TLS 1.2, the more narrowly-scoped option, so I consider my question satisfied. :-) On Sat, Dec 17, 2022 at 12:03 PM Yaron Sheffer <[email protected]> wrote: > Hi Carrick, > > > > While this is clear to the authors, it is not very clear in the document. > Even though the document only applies to TLS 1.2, TLS 1.2 (the version > number) is not mentioned in the doc title, in the abstract or in the > introduction. > > > > Thanks, > > Yaron > > > > *From: *TLS <[email protected]> on behalf of Carrick Bartle < > [email protected]> > *Date: *Thursday, 15 December 2022 at 20:15 > *To: *David Benjamin <[email protected]> > *Cc: *TLS List <[email protected]> > *Subject: *Re: [TLS] consensus call: deprecate all FFDHE cipher suites > > > > 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 <[email protected]> > 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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ TLS mailing list > [email protected] https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
