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 email starts the working group last call for "Deprecating Obsolete
> >> Key Exchange Methods in TLS 1.2” I-D, located here:
> >
> >> . https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex
> >
> > Three minor issues and a question.
> >
> > Consider saying once, early.in the document, that this does not
> > address TLS 1.0 and TLS 1.1 as they were already deprecated.
>
> 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.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
