On Tue, Jun 30, 2026 at 01:06:43PM +0000, Yaakov Stein wrote:
> > It makes sense to let the user pick what suits best. That has been the
> > traditional approach at IETF
> Actually, the traditional approach at the IETF has been to sanction a
> single mandatory-to-implement approach supplemented by
> optional-to-implement alternatives when these have strong use cases
> not well treated by the mandatory approach.
Where "strong" means "occasionally" or "in some situations" useful,
rather than cryptographically string. Thus, for example, TLS 1.0
through 1.2 had both NULL authentication:
TLS_DH_anon_WITH_AES_256_GCM_SHA384
TLS_DH_anon_WITH_AES_128_GCM_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA256
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256
TLS_ECDH_anon_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA
TLS_ECDH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_SEED_CBC_SHA
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA
TLS_ECDH_anon_WITH_NULL_SHA
and NULL encryption
TLS_ECDHE_ECDSA_WITH_NULL_SHA
TLS_ECDHE_RSA_WITH_NULL_SHA
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA
TLS_RSA_WITH_NULL_MD5
ciphers, and even one that was both:
TLS_ECDH_anon_WITH_NULL_SHA
which were there because they are useful (and are missed in TLS 1.3).
These are for alternative use-cases, rather than alternatives for the
same use-case, but lately in the IETF we seem to believe there's one
use-case to rule them all.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
