4 ms·

> Someday, WireGuard will need to be upgraded to support a second cipher suite. When this happens, users will be able to configure it peer-by-peer to allow one

> Someday, WireGuard will need to be upgraded to support a second cipher suite. When this happens, users will be able to configure it peer-by-peer to allow one cipher suite or the other, or both, exactly as they would with any other VPN. Is that accurate? I thought they explicitly said that this is not the case, that instead a V2 would still have just the one protocol? In any case it's a non-problem, as you simply migrate by setting up V2 on a different port, and migrate client by client.

alfiedotwtf 5y ago
I'd say better this that having "cipher agility" like with IPSec. During design of IPSec, someone was advocating for the "NULL cipher" which is essentially no-encription where the use case was "debugging". Tie in cipher agility with the NULL cypher, and you've got yourself an awesome downgrade attack
Shish2k 5y ago
“Set up a new service and migrate all your clients” sounds _worse_ than “update the centrally managed config for existing clients” though? I’m only dealing with double-digit numbers of devices, and this “non-problem” sounds like a nightmare...
- tptacek 5y ago
  You are in fact unlikely to ever have to upgrade the WireGuard protocol under any kind of duress. But ciphersuite negotiation has itself been a source of protocol vulnerabilities, and those are vulnerabilities you'll never have to think about with WireGuard.
- whoknowswhat11 5y ago
  Not for larger enterprises - simply because this is how they ALREADY do things. You setup new thing on new place, and 5 years later hope you can turn off version 1. You would be surprised at how LITTLE updating and reconfiguring of systems that are working big enterprises want to do. And this is doubly so in the VPN space which is a mindfield already of troubleshooting when users call and complain (98% user error, but the 2% config / ip exhaustion or whatever bites you and so once folks have a working setup they really don't want to mess with it).
- knorker 5y ago
  If you have triple-digit clients then you need automation anyway. What's so hard about rolling out a config change? And it's not like you don't have this with IPSec. It's just a different config change, maybe enabling PFS, or changing the allowed crypto list, etc.

alfiedotwtf 5y ago

I'd say better this that having "cipher agility" like with IPSec. During design of IPSec, someone was advocating for the "NULL cipher" which is essentially no-encription where the use case was "debugging". Tie in cipher agility with the NULL cypher, and you've got yourself an awesome downgrade attack

Shish2k 5y ago

“Set up a new service and migrate all your clients” sounds _worse_ than “update the centrally managed config for existing clients” though? I’m only dealing with double-digit numbers of devices, and this “non-problem” sounds like a nightmare...

tptacek 5y ago
You are in fact unlikely to ever have to upgrade the WireGuard protocol under any kind of duress. But ciphersuite negotiation has itself been a source of protocol vulnerabilities, and those are vulnerabilities you'll never have to think about with WireGuard.
whoknowswhat11 5y ago
Not for larger enterprises - simply because this is how they ALREADY do things. You setup new thing on new place, and 5 years later hope you can turn off version 1. You would be surprised at how LITTLE updating and reconfiguring of systems that are working big enterprises want to do. And this is doubly so in the VPN space which is a mindfield already of troubleshooting when users call and complain (98% user error, but the 2% config / ip exhaustion or whatever bites you and so once folks have a working setup they really don't want to mess with it).
knorker 5y ago
If you have triple-digit clients then you need automation anyway. What's so hard about rolling out a config change? And it's not like you don't have this with IPSec. It's just a different config change, maybe enabling PFS, or changing the allowed crypto list, etc.