3 ms·
If you have multiple WireGuard versions, in a migration setting, you also need to do some negotiation at the start, no? Wouldn't that be potentially vulnerable
by est31 4y ago
If you have multiple WireGuard versions, in a migration setting, you also need to do some negotiation at the start, no? Wouldn't that be potentially vulnerable to downgrade attacks as well?
- tptacek 4y agoNo: you simply don't speak the old versions.
- est31 4y agoSo the migration looks like "upgrade the client or you won't be able to connect to the server any more"? What if you use the client to talk to multiple servers, some that use the old version, some that use the new version? Maybe via a config variable adjustable per server? Then you do out of band version negotiation, and you might get away with this in the VPN setting, where entering arcane config vars is commonplace, but not in e.g. the TLS setting.
- tptacek 4y agoEntering arcane config variables is extremely not commonplace with WireGuard.
- est31 4y agoI guess that's thanks to the fact that WireGuard is a new system and new systems have little legacy bloat. Maybe the WireGuard author had golden hands, and the system is perfect, and indeed it it is quite good, but I think instead that WireGuard will eventually require a new version. Then one such solution will have to be chosen.
- some_furry 4y agoWhen that happens, you will use WireGuard v2 which is incompatible with WireGuard v1. I wouldn't expect it to happen before a crypto-relevant quantum computer is built.
- some_furry 4y agoI wrote a lot about a similar debate recently, but in the context of encryption at rest rather than encryption in transit https://soatok.blog/2022/08/18/burning-trust-at-the-quantum-village-at-defcon-30/ https://soatok.blog/2022/08/18/burning-trust-at-the-quantum-... For brevity, start reading at "Isn’t cryptography fun?" which contains the relevant portion.