Hi misc. I was reading RFC9325[1] (released November of 2022), and noticed this
under section 4.1 (General Guidelines, under Recommendations: Cipher Suites):
* Implementations MUST support and prefer to negotiate cipher suites
offering forward secrecy. However, TLS 1.2 implementations SHOULD
NOT negotiate cipher suites based on ephemeral finite-field
Diffie-Hellman key agreement (i.e., "TLS_DHE_*" suites). This is
justified by the known fragility of the construction (see
[RACCOON]) and the limitation around negotiation, including using
[RFC7919], which has seen very limited uptake.
Yet in lib/libtls/tls_internal.h, I see this section.
#define TLS_CIPHERS_DEFAULT "TLSv1.3:TLSv1.2+AEAD+ECDHE:TLSv1.2+AEAD+DHE"
#define TLS_CIPHERS_COMPAT "HIGH:!aNULL"
#define TLS_CIPHERS_LEGACY "HIGH:MEDIUM:!aNULL"
#define TLS_CIPHERS_ALL "ALL:!aNULL:!eNULL"
I forget what exactly led me to find it. I think I might've been trying to
figure out what the relationship between SSL_CTX_set_cipher_list(3) and
tls_config_set_ciphers(3) was, because I didn't know what setting ciphers to
"default" or "secure" in httpd.conf(5) or relayd.conf(5) actually did. Finding
this made that a lot more clear.
Anyway, I'm mailing because I wanted to ask this: why does OpenBSD includes DHE
cipher suites in TLS_CIPHERS_DEFAULT? Is it at all related to
tls_config_set_dheparams(3) being set to none by default?
I'm not the most educated about TLS and cryptography, so I felt I should ask
before jumping to any conclusions. There may be a valid reason for all I
know---it's a question based on an observation rather than a criticism.
[1]: https://www.rfc-editor.org/info/rfc9325
