> There are no ECDHE or FFDHE cipher suites in TLS 1.3. Cipher suites specify > just the bulk encryption, PRF, and integrity protection mechanism. The key > exchange is fully controlled by . Ah, good point :-) Maybe go with this text instead? In TLS 1.3 connections, clients and servers MAY offer supported_groups and key_share extensions corresponding to FFDHE (note that in TLS 1.3, the key exchange is not determined by the cipher suite, but rather by these extensions).
On Thu, 13 Jul 2023 at 16:04, Hubert Kario <hka...@redhat.com> wrote: > On Wednesday, 12 July 2023 19:13:02 CEST, Viktor Dukhovni wrote: > > On Wed, Jul 12, 2023 at 12:40:13PM -0400, Sean Turner wrote: > > > >>> On Jul 11, 2023, at 13:52, Salz, Rich <rs...@akamai.com> wrote: > >>> ... > >> > >> This appears in s2: > >> > >> Note that TLS 1.0 and 1.1 are deprecated by [RFC8996] > >> and TLS 1.3 does not support FFDH [RFC8446]. > > > > And section 3: > > > > > > > https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-02.html#section-3 > > > > Clients MUST NOT offer and servers MUST NOT select FFDHE cipher > > suites in TLS 1.2 connections. This includes all cipher suites > > listed in the table in Appendix C. (Note that TLS 1.0 and 1.1 are > > deprecated by [RFC8996].) FFDHE cipher suites in TLS 1.3 do not > > suffer from the problems presented in Section 1; see [RFC8446]. > > Therefore, clients and servers MAY offer FFDHE cipher suites in TLS > > 1.3 connections. > > > > Note that at least in Postfix (opportunistic STARTTLS), this advice will > > be ignored. FFDHE will remain supported in TLS 1.2, with ECDHE > > preferred when offered by the client: > > > > https://tools.ietf.org/html/rfc7435 > > > > The default group used by the server is either a compiled-in 2048-bit > > group or one of the groups from appendix of RFC7919 built-in to OpenSSL. > > There are zero reports of clients that can't handle 2048-bit groups (as > > opposed to 1024). Point "3" in the introduction may be outdated w.r.t. > > to current practice. > > > > And in general, it's far better to use FFDHE kex with legacy client than > RSA. > Getting RSA right is very hard, using ephemeral secrets for FFDHE is > trivial > and recommended practice already. > > also > > > Therefore, clients and servers MAY offer FFDHE cipher suites in TLS > > 1.3 connections. > > There are no ECDHE or FFDHE cipher suites in TLS 1.3. Cipher suites specify > just the bulk encryption, PRF, and integrity protection mechanism. The key > exchange is fully controlled by supported_groups and key_share extensions. > -- > Regards, > Hubert Kario > Principal Quality Engineer, RHEL Crypto team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic > > _______________________________________________ > 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
