Relationship between TLS 1.3 ciphers and earlier ciphers

[Jordan Brown]

For context, here's the previous exchanges in this thread: 
https://mta.openssl.org/pipermail/openssl-users/2023-May/016349.html

Having gotten back to this project and dug into it some more, it's a
real nuisance to have to maintain separate pre-1.3 and post-1.3 cipher
lists.  It involves duplicated variables, duplicated (or more complex)
functions, duplicated user interface, et cetera.

Why would it be wrong for the one SSL_set_ciphersuites() function to
accept both pre-1.3 and post-1.3 cipher names (as it does!) allowing the
pre-1.3 ciphers on pre-1.3 connections and the post-1.3 ciphers on
post-1.3 connections?  That seems equivalent to the behavior when new
ciphers were added in 1.2:  the new ciphers only worked for 1.2
connections.  And it seems like the only answer for future transitions: 
if 1.4 deletes cipher A and adds cipher B another, surely you would not
add still a third function; surely you would add B to
SSL_set_ciphersuites(), and A would work only on 1.3 connections and B
would work only on 1.4 connections.

(Note:  I understand that the names used by SSL_set_cipher_list() and
SSL_set_ciphersuites() are different, and that SSL_set_cipher_lists()
allows patterns while SSL_set_ciphersuites() does not.  We abandoned
pattern matching years ago, and consistently using IANA names, with
minimal provision for backward compatibility, would be better than using
OpenSSL names for older ciphers and IANA names for new ciphers.)

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20231130/49cf7f9a/attachment.htm>