TLS 1.3 migration: SSL_set_cipher_list vs SSL_set_ciphersuites and "aliases" of families of cipher like TLSv1.3

[Romain GEISSLER]

> Le 1 avr. 2020 à 15:19, Salz, Rich <rsalz at akamai.com> a écrit :
> 
>>   - Do you think any use for supporting some kind of alias for families of cipher in SSL_set_ciphersuites, like for example "TLSv1.3"
> 
> Suppose someone finds out that chacha/poly is insecure and the IETF issues a new RFC that says "TLS 1.3 MUST NOT use" that cipher.  Should the openssl alias change?
> 
> It can be wordy, but explicitly listing ciphers and not using aliases (HIGH EXPORT etc) is really better.
> 
> As for ease of use, just don't allow the ciphers to be configured.
> 

Hi,

Well, as a user of openssl, in the same scenario, I would draw the exact opposite conclusion ;)

Let me elaborate. We as users don’t really know well how secure is a cipher, and we don’t really OpenSSL nor IETF discussions about these details. I am not saying they don’t matter, of course not, but as users, we are not expert of this, and we don’t follow it. However, what we do is follow regularly releases of OpenSSL: when a new stable release is out, we quickly migrate to it. As a user, I would see an added value to define aliases, because I definitely don’t want to hardcode in our config that we explicitly allow the usage of ciper X, Y or Z, as this config might "rot" over time and not follow state of the art config. However I do want to express the fact that I either allow any default ciphers (ie some kind of default config that would be based on OSSL_default_ciphersuites), or that I explicitly want to support the TLS 1.3-compliant ciphers but not the TLS 1.4 ones (if one day 1.4 is out, and for some reason, they can’t use the same set of default ciphers). This way we users express high level needs (ie famillies of ciphers), and you OpenSSL developer ensure the details of it, and make the alias content evolve over time if one day a cipher is found to be weak. So yes to answer your question, the openssl alias name should stay the same, but its actual meaning (ie ciper suite list) should evolve over time.

This is one opinion, from user perspective. At least this is the vision we were used to with cipher lists for TLS <= 1.2, in which we definitely didn’t want to explicitly hardcode a list of ciphers about which we honestly have no idea of their cryptographic security, alias "TLSv1.2" was convenient.

Cheers,
Romain