You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello 👋,
Nice to meet you, I am glad that you are interested on Sōzu using Rustls. We do not have plan to change of crypto provider yet, maybe we should plan it. However, I am not a huge fan on introducing experimental features on Sōzu as we used for production and we want it to be as stable as possible. If we do implement another crypto provider today, it will be aws-lc in addition to ring, it will make more sense to me.
thanks for the reply! i was under the impression that sozu was already using rustls for crypto, which is why i was asking about it 😅
in any case, would you consider it as an optional feature that users could enable at their whim (i agree that enabling experimental features by default isn't a great idea)?
harvest now decrypt later1 is a real threat today. for those looking for a secure proxy for their servers who have this attack in their threat model, this would be a good feature for sozu to offer, even if opt-in. it's already an optional feature of other proxies2 like nginx3 and caddy4 (albeit if the user decides to compile them themselves, though in caddy's case this is trivial using xcaddy)
regarding aws-lc, it too offers post-quantum cryptography5, whereas ring is planning to add it but hasn't as of yet6
edit: sorry, re-reading my original comment i realize i misunderstood your reply. while ring doesn't offer ml-kem, and aws-lc-rs does, perhaps offering it as an opt-in feature is worth considering? i haven't really taken a deep look at the code to see how much work that'd entail
rustls offers experimental post quantum crypto via kyber:
https://docs.rs/rustls-post-quantum/latest/rustls_post_quantum/
is this an option to enable for sozu? should it be considered if not?
The text was updated successfully, but these errors were encountered: