Closed dcmgashcisco closed 2 years ago
I might have already addressed this in S8.1.4 of branch heas-tls, which I am about to merge.
Indeed, I think this is address in S8.1.4. Please review that section in relation to this PR and TLS algorithm suggestions in general, @dcmgashcisco @td-tacacs. Passing the PR to @dcmgashcisco
8.1.4 looks good to me. One suggestion:
"Unfortunately, no single and timely TLS recommendations document exists." I would change that to "... exists today." We may get an RFC that unifies all other RFCs in the future.
Done, in 11036e2234. Douglas, to you.
Looks good to me.
We agreed to close.
I think the below says, that deprecated versions MUST be deprecated, then says they MAY be supported (as long as they are configured)?
I wonder if we can simplify this by acknowledging that it is difficult to deprecated versions and just say "deprecated versions SHOULD be abandoned at earliest possible time"
...and MUST abandon TLS versions as they are deprecated, including TLS 1.3 and prior versions.
Clearly deprecation is more difficult for Servers, because support for and deployment of new TLS versions to Clients will occur with great randomness or perhaps not at all due to End of Support (EoS). Therefore, it is of great value to, and implementations MAY, support deprecated versions to allow for gradual adoption and software at its End of Life (EoL). A Server that supports deprecated versions SHOULD NOT enable this support except by operator configuration.