I'm sure the options will balloon a bit. After all, if someone develops a new good cipher/etc, we'll want to use it in TLS. But it's nice that as of now, there's no bad choices available (other than potentially allowing downgrading).
It's entirely possible we will never need to replace AES (or indeed ChaCha20). AES 128 GCM is mandatory to implement, and implementers are recommended to offer ChaCha20 too. If you don't have AES hardware, ChaCha20 looks very attractive and you'd be a fool not to.
So while you can get code points for a vanity cipher, there not only isn't an appetite from the working group to endorse such ciphers, there is unlikely to ever be a scenario where a client or server would actually pick it unless you control both and choose to prefer the vanity cipher. Whereupon why bother?
The downgrade prevention in TLS 1.3 is pretty effective, so an attack which needs a downgrade also needs to defeat the downgrade protection, an additional hurdle. Obviously people should get rid of TLS 1.0 and TLS 1.1 but meanwhile I think the anti-downgrade story is the best it has ever been.
We may never need to replace AES 256, but Grover's quantum search algorithm can break AES 128 with a work factor of 2^64. AES 256 GCM and a post-quantum authenticated key agreement algorithm may be all we ever need.
While it's true what you say about Grover's algorithm, I remain sceptical that this can actually be made practical. And if it does become practical as you point out the post-quantum kex is the big must-have anyway. As this toy implementation shows, TLS has at least four symmetric keys for each session, whereas you'd only need to break one kex to get them all.
So I'm comfortable with my claim as it stood, we might never even need AES 256 in practice (but like ChaCha20 it's a SHOULD in the RFC for TLS 1.3).
Everyone likes to bikeshed, but I'm a bit disappointed that TLS 1.3 kept the ability to use pre-shared-keys without (EC)DHE.
I get that the intended use case is not paying the overhead of asymmetric crypto for embedded applications. However, that use case is already covered by something like WolfSSL stripped down to only support TLS 1.2 PSK, and they can still even use modern AEAD cihper suites like AES 256 GCM in TLS 1.2.
All of the TLS 1.3 key agreement mechanisms should have forward secrecy, even when pre-shared-keys are used. In some applications, there's too much temptation to get rid of that safety net for efficiency. We shouldn't clutter up the TLS 1.3 spec and implementations to cover that use case. Furthermore, engineers who go that route should have to explain to their boss solid engineering reasons why they're staying back at TLS 1.2. There are a small number of valid use cases for symmetric-only key exchange, but there are way more use cases where an engineer just thinks the reduced overhead is worth the risk, and their manager sees the TLS 1.3 box checked and thinks they're fine.
We can't force people to do security. There definitely are (hopefully not publicly exposed) TLS 1.3 server implementations which always pick the same private key to do ECDHE, even though this means they lose forward secrecy - because they did not want actual security and we can't make them.
Comments
I'm sure the options will balloon a bit. After all, if someone develops a new good cipher/etc, we'll want to use it in TLS. But it's nice that as of now, there's no bad choices available (other than potentially allowing downgrading).
It's entirely possible we will never need to replace AES (or indeed ChaCha20). AES 128 GCM is mandatory to implement, and implementers are recommended to offer ChaCha20 too. If you don't have AES hardware, ChaCha20 looks very attractive and you'd be a fool not to.
So while you can get code points for a vanity cipher, there not only isn't an appetite from the working group to endorse such ciphers, there is unlikely to ever be a scenario where a client or server would actually pick it unless you control both and choose to prefer the vanity cipher. Whereupon why bother?
The downgrade prevention in TLS 1.3 is pretty effective, so an attack which needs a downgrade also needs to defeat the downgrade protection, an additional hurdle. Obviously people should get rid of TLS 1.0 and TLS 1.1 but meanwhile I think the anti-downgrade story is the best it has ever been.
We may never need to replace AES 256, but Grover's quantum search algorithm can break AES 128 with a work factor of 2^64. AES 256 GCM and a post-quantum authenticated key agreement algorithm may be all we ever need.
While it's true what you say about Grover's algorithm, I remain sceptical that this can actually be made practical. And if it does become practical as you point out the post-quantum kex is the big must-have anyway. As this toy implementation shows, TLS has at least four symmetric keys for each session, whereas you'd only need to break one kex to get them all.
So I'm comfortable with my claim as it stood, we might never even need AES 256 in practice (but like ChaCha20 it's a SHOULD in the RFC for TLS 1.3).
Everyone likes to bikeshed, but I'm a bit disappointed that TLS 1.3 kept the ability to use pre-shared-keys without (EC)DHE.
I get that the intended use case is not paying the overhead of asymmetric crypto for embedded applications. However, that use case is already covered by something like WolfSSL stripped down to only support TLS 1.2 PSK, and they can still even use modern AEAD cihper suites like AES 256 GCM in TLS 1.2.
All of the TLS 1.3 key agreement mechanisms should have forward secrecy, even when pre-shared-keys are used. In some applications, there's too much temptation to get rid of that safety net for efficiency. We shouldn't clutter up the TLS 1.3 spec and implementations to cover that use case. Furthermore, engineers who go that route should have to explain to their boss solid engineering reasons why they're staying back at TLS 1.2. There are a small number of valid use cases for symmetric-only key exchange, but there are way more use cases where an engineer just thinks the reduced overhead is worth the risk, and their manager sees the TLS 1.3 box checked and thinks they're fine.
We can't force people to do security. There definitely are (hopefully not publicly exposed) TLS 1.3 server implementations which always pick the same private key to do ECDHE, even though this means they lose forward secrecy - because they did not want actual security and we can't make them.