As initially pointed out by @chantra , supporting a standardized construction would be nice.
From a security standpoint, there's nothing wrong with Box-ChaChaPoly.
The construction is very boring in a good way.
No signs of any practical vulnerability was ever found, key setup is virtually free, it is highly parallelizable and gets faster with each CPU generation while remaining fast on constrained devices.
So, there's no need to change something rock solid.
However, it's an issue for specifications. Even if it's based on standardized building blocks, we have to describe how to implement it. Annex.1 in the current RFC is as large as the rest of the document and doesn't even include pseudo-code.
In practice, people just use implementations already available for their language. But it's still annoying for the specification.
We could easily add support for the IETF version of ChaChaPoly, without changing much of the protocol, not even nonce sizes. That requires one or two calls to a KDF to derive a subkey and a nonce, and using HKDF may be a bit slower than the current hchacha round, but it's not the end of the world.
An even more standard-y alternative would be to use HPKE with deterministic keys. That requires many more KDF calls, but we then wouldn't even have to explain how to compute shared keys.
HPKE comes with a few issues and open questions, though:
Increased implementation size and complexity (even though implementations already exist for common languages)
Slightly slower, due to more KDF calls
Configuration (should it be part of the certificate? Shall we support all ciphers, hashes and KEMs?)
When used with AES-GCM: cost of key setup, which can ruin performance.
More intrusive changes to the protocol are required.
From a user perspective, there wouldn't be any benefits at all over what we currently have. On the other hand, it can help with adoption, especially if Anonymized DNSCrypt can prove to be faster than DNS over Oblivious HTTP/3 while remaining way easier to implement.
As initially pointed out by @chantra , supporting a standardized construction would be nice.
From a security standpoint, there's nothing wrong with
Box-ChaChaPoly.The construction is very boring in a good way.
No signs of any practical vulnerability was ever found, key setup is virtually free, it is highly parallelizable and gets faster with each CPU generation while remaining fast on constrained devices.
So, there's no need to change something rock solid.
However, it's an issue for specifications. Even if it's based on standardized building blocks, we have to describe how to implement it. Annex.1 in the current RFC is as large as the rest of the document and doesn't even include pseudo-code.
In practice, people just use implementations already available for their language. But it's still annoying for the specification.
We could easily add support for the IETF version of ChaChaPoly, without changing much of the protocol, not even nonce sizes. That requires one or two calls to a KDF to derive a subkey and a nonce, and using HKDF may be a bit slower than the current
hchacharound, but it's not the end of the world.An even more standard-y alternative would be to use HPKE with deterministic keys. That requires many more KDF calls, but we then wouldn't even have to explain how to compute shared keys.
HPKE comes with a few issues and open questions, though:
From a user perspective, there wouldn't be any benefits at all over what we currently have. On the other hand, it can help with adoption, especially if Anonymized DNSCrypt can prove to be faster than DNS over Oblivious HTTP/3 while remaining way easier to implement.