Good point, we'll add that to the intro and title. On Sat, Dec 17, 2022 at 9:03 AM Yaron Sheffer <yaronf.i...@gmail.com> 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 <tls-boun...@ietf.org> on behalf of Carrick Bartle < > cbartle...@gmail.com> > *Date: *Thursday, 15 December 2022 at 20:15 > *To: *David Benjamin <david...@chromium.org> > *Cc: *TLS List <tls@ietf.org> > *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 <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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
