[Slavius]

Yet still it spreads lies. There's not only 4 pieces of information needed to establish IPsec (they even cannot count as they mention 5 pieces). In addition to named remote and local IP addresses, subnets and a pre-shared key you also need: * mode of operation (transport or tunnel) * exchange mode (base, main, aggressive or ikev2) * policy mode of operation (encrypt and/or protect - yes encryption is optional with IPsec) * Phase 1 parameters (hashing algorithm(s) + encryption algorithm(s)), key lifetime in bytes or seconds * Whether you/remote uses a PFS (if so, then also DH Group) * Phase 2 parameters (hashing algorithm(s) + encryption algorithm(s)), key lifetime in bytes or seconds * Whether or not to use NAT traversal (changes the protocols and ports needed to be opened on the firewall(s))

If you don't know some of these parameters chances are you won't be able to establish the tunnel no matter how hard you try.

Plus you need to know all the vendor quirks as establishing IPsec from Cisco to Fortigate or Sophos is not straightforward.

Then you may end up playing with NAT-exclusions, SNAT/DNAT if both sides of the tunnel have the same or overlapping IP ranges.

Setting up IPsec is definitely not an exchange of 4 parameters...

[Spivak]

I think the point is that if you “WireGuard-ify” IPSec and just fix all those parameters (e.g. take the vendor defaults) then you’re left with 5 pieces of information.

If the value of WG is just that it forces all these parameters to be static then the best thing we could do is come up with the “WireGuard” IPSec profile call it a day.

[Slavius]

Are you saying that fixed parameters chosen for no apparent reason by the WireGuard developers are better than modularity and interoperability of IPsec? What if in a few months ChaCha20 gets proven insecure due to collisions found or easy factorisation? What can WireGuard offer to mitigate that? Shouldn't then also browsers implement only TLS1.3 and ed25519 ciphers because they are currently the most secure?

[growse]

> .. for no apparent reason by the WireGuard developers...

It's a very weird assertion that the Wireguard devs just threw the software together at random, choosing parameters for "no apparent reason".

> What if in a few months ChaCha20 gets proven insecure due to collisions found or easy factorisation? What can WireGuard offer to mitigate that? Shouldn't then also browsers implement only TLS1.3 and ed25519 ciphers because they are currently the most secure?

TLS is famously susceptible to downgrade attacks. (https://blog.ivanristic.com/2013/09/is-beast-still-a-threat.... etc.)

Ultimately, it's a value judgement. You can either have resistance to downgrade attacks (which have themselves proven to be quite problematic), or you have interoperability across multiple versions and configurations of endpoints. Increase the configurability of the protocol, and you massively increase the complexity. Increased complexity means increased testing burden and ultimately increased risk.

If Wireguard needs to be fixed in a backwards-incompatible way, then we'll find ourselves with a new version of Wireguard that doesn't work with the old version.

[Spivak]

> new version of Wireguard that doesn't work with the old version.

Right, and maybe this is actually in improvement in security overall but it just externalizes the downgrade attack since once there are multiple versions of WG floating around with different vendors/clients only supporting a specific version you end up similarly vulnerable since you need to run multiple WG endpoints of different versions.

And since it’s a kernel module you’ve made the hassle of doing so very annoying compared to one line in a config file.

IPSec feels messy and complex specifically because the world is messy and complex. WG is fantastic and I love it dearly for “the 90% case” where I have total control over all peers.

[upofadown]

>TLS is famously susceptible to downgrade attacks.

The article is from 8 years ago so I would suggest that the fame has mostly faded. TLS downgrade attacks are not a thing in practice. A system with non-upgradable and broken crypto is much worse than something that requires a MITM attack to get at the broken crypto. I am not sure why there are opinions to the contrary. In either case you still have to fix things. The non-upgradable case will just be much much harder.

[Spivak]

Absolutely not! What I mean is that I don’t think that IPSec having a bunch of tunables like this should count as harshly as the parent implies when it comes to configuration complexity because WireGuard isn’t all that different — the tunables are just chosen earlier in a way that’s not user-visible.