Re: Relationship between TLS 1.3 ciphers and earlier ciphers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux