News for hackers. Stuff that matters.
Re:WireGuard: Next Generation Kernel Network Tunnel [pdf] by nickik on Monday August 06, 2018 @06:51PM (#17702471)
Yes. But in the real world negotiation has consistently been a huge problem leading to lots and lots of problems.

I rather put my stack into the best currently known crypto rather then a highly complex cipher negotiation process.

Re:WireGuard: Next Generation Kernel Network Tunnel [pdf] by dennisjac on Monday August 06, 2018 @08:57PM (#17703089)
In terms of negotiation there is a lot of room between the two extremes of "none" and "highly complex" but I agree that one of the big appeals of Wireguard is that you no longer have to fill out weird spec sheets to coordinate the used cipher suites with the admin on the other side of the connection.

Having said that I still would have preferred for something like a single increasing integer as the "cipher suite version". This would have allowed for the option of updating Wireguard asynchronously on both ends without any additional configuration or cipher suite coordination with the peer.

Re:WireGuard: Next Generation Kernel Network Tunnel [pdf] by zx2c4 on Tuesday August 07, 2018 @03:05AM (#17704393)
> Having said that I still would have preferred for something like a single increasing integer as the "cipher suite version".

This already essentially exists. If the first byte of an initiation message is 0x1, then it means you're using "Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s" "WireGuard v1 zx2c4 [email protected]". It seems like this thread is going in circles based on incorrect information about how the thing actually works.

Re:WireGuard: Next Generation Kernel Network Tunnel [pdf] by dennisjac on Tuesday August 07, 2018 @05:42AM (#17705039)
As you have stated elsewhere negotiation has been a huge problem in other protocols and makes things much more complicated and I agree with that. My concern was merely with how absolute this stance is i.e. if the sentiment runs along the line "Wireguard will only ever support a single version and potential upgrade paths are the problem of the users" or more like "Wireguard will avoid negotiation wherever possible but when the cipher primitives are deprecated (not broken) by the community we might support introducing a replacement but keeping support for the old primitives for a while for upgrade purposes".

Have you considered mentioning the way you intend to deal with cipher breakage/deprecation more explicitly on the Wireguard page?

Re:WireGuard: Next Generation Kernel Network Tunnel [pdf] by beagle3 on Tuesday August 07, 2018 @02:52AM (#17704352)
... but, that's exactly the root cause of previous failures. wireguard is basically saying "we don't know how to do that well enough, so we're not baking it in for now".

Why does the "increasing integer" matter to you? In what way is it better than "I am willing to protocol 1, 4 and 7" (implicitly "but not 2, 3, 5, 6, 8, 9, 10,"...)? And the "I am willing to .." is just a successful handshake. You try in order of preference; If you succeed, other side supports it. If you don't, you go to the next one. Wireguard does not produce a response unless to a non-confirming attempt.