> Le 1 avr. 2020 à 15:19, Salz, Rich <rs...@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

Reply via email to