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
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.