I'd like to see the bits of the cipher suite associated entirely with ephemeral data tied together roughly by security margin, to avoid combinations that don't make sense (e.g., straw men of RSA384 + AES256 or AES256 + CRC32). This means: the type/size of the (EC)DHE group and the symmetric cipher (and possibly the MAC, if it's anything other than "GCM"). So, you'd potentially have something like
ECDHE256-AES256-GCM DHE2048-AES256-GCM DHE1536-AES128-GCM etc. The signature algorithm (ECDSA, RSA, etc.) would be entirely separate. This isn't like the old days when the RSA key was used to exchange the keys: in the FS world, RSA is never used for key agreement, so RSA/ECDSA is used only to authenticate the server and is therefore orthogonal to the cipher suite negotiated above... and it's also implicit from the set of certificates the server has available. This unfortunately means we can't really tie the signature security margin to the cipher suite (going back to the RSA384 straw man), but since it's a pre-existing credential nothing can be done by the client other than to hang up if it's spooked by that. To fix this, we'd really need to go down the road of specifying the key size in the cipher suite, e.g. RSA2048 or ECDSA25519, which I'm not sure anyone wants. Does anyone want that? I ask because there are a ton of servers with 1024-bit RSA keys negotiating AES256-GCM, which tells an attacker exactly what to focus on. (In theory: a tire iron is still probably faster than factoring RSA1024.) The nice thing about the above approach is that IMO it actually makes things simpler for an implementer: the cipher suite list becomes a lot smaller but still covers most of the options, avoiding the complexity of full a la carte, while the signature algorithm is implicit for the server. So, we're not at libsodium level of simplicity, but closer. The one thing I'm having trouble pinning down is PSK. I fear it's not a separate dimension, because it replaces both signature and KEX. Kyle _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
