
WireGuard: Next Generation Kernel Network Tunnel [pdf] - tosh
https://www.wireguard.com/papers/wireguard.pdf
======
nostream
I'm a big fan of WireGuard. But it gives a bad taste in the mouth to know that
the author banned a WireGuard fan and user from the IRC channel just because
he took time to code and release a free Windows client for the protocol. And
that the WG author spend time to talk shit about this client whenever he has a
chance, for example when the Windows client author announce it here.

The protocol is quite easy to get into, it is well documented to the extent
that it is easy to believe that it is in WireGuard's interest that more people
develop software that supports the protocol.

Maybe the WireGuard homepage should make an official statement that anyone who
implement the protocol and release a client is no longer welcome in the
community to discuss the protocol or listen when other people discuss the
protocol.

The WG author mentioned in the mailing list that he has reverse engineered
Tunsafe and found security flaws. I would like to see that he presents these
security shortcomings in order to legitimize his claim instead of keeping it
secret. As he is a representative of a security company, it might be a good
tactic to not hurt his reputation as it is practice in the security industry
to share such information.

------
vxNsr
I'm a little off-put by the creator's attitude towards clients he didn't have
a hand in making[0]. And the fact that 5 months ago he said we'd have a
windows client around the corner, and yet after taking a cursory look at the
two projects, development on one appears to be stalled, and the other still
can't support windows, doesn't bode well.

I'm insanely impressed that he's come up with something so good, and I have no
knowledge of cryptography and writing truly secure code, so I don't like to
complain like this... but it would be nice to have a real timeline so that we
can make our own decision about whether we want to use the closed source
alternatives.

[0][https://news.ycombinator.com/item?id=16515637](https://news.ycombinator.com/item?id=16515637)

~~~
akivabamberger
Your comment is very misleading. Reading what you linked to, creator has the
(extremely legitimate) concern of users relying on closed source
implementations of WireGuard. Which is not at all the same as "clients he
didn't have a hand in making"

~~~
vxNsr
I read that based on his ignoring tunsafe's author's comments, and the fact
that he apparently unilaterally blanned the author from the wireguard
subreddit.

I don't know either person at all, I only found out about tunsafe and the
"controversy" a few hours ago after seeing this post and googling for the
windows alternatives that "are not recommended" but are mentioned on the
wireguard site.

I admit I did editorialize a bit more than I should have.

------
dennisjac
I'm a bit unsure about the fact that Wireguard has no negotiation capabilities
whatsoever. On the one hand this feature makes the configuration of tunnels
dead simple as opposed to e.g. IPSec but on the other hand it also means that
all participating systems are extremely tightly coupled. If one system updates
to a kernel that contains a Wireguard version with crypto changes then all
peers _have_ to update their Wireguard versions at the exact same time or the
tunnels break. This is easy if you have point-to-point tunnels where you
control both ends of the connection but could potentially be a nightmare for
tunnels to other companies or road-warrior setups. I fear that in these cases
many will be forced to stick with IPSec due to these constraints.

~~~
nickik
No. If a new version of WireGuard comes out with new capabilities it would be
done by having that new version understand the old system and you can make a
choice if you support it or not.

However that will not really be an issue for a many years and there are many
ways how that can be handled in the future.

~~~
dennisjac
You cannot really predict this because you don't know when a weakness in a
cypher is discovered. Yes it might never happen but it might also happen three
days from now. Any piece of software that involves cryptography must be able
to change the used primitives quickly in case they are compromised.

Where do you have the information about how Wireguard would handle such a
transition from? Looking at
[https://www.wireguard.com/protocol/](https://www.wireguard.com/protocol/) I
can see no protocol version or other means to distinguish between an old and
new version of the protocol. Also this would introduce additional
configuration and a negotiation step which seems to run counter to the
motivation of the project.

Not preparing for for this inevitability seems foolish which leads me to
believe that this was not an oversight but a deliberate design decision by the
creators of Wireguard.

~~~
beagle3
The discussion in
[https://news.ycombinator.com/item?id=17690815](https://news.ycombinator.com/item?id=17690815)
is meaningful. There is, apparently, some disagreement about how the protocol
versioning should be interpreted: zx2c4 (J.Donenfeld, wg creator) refers to
the "v1" string used in the construction as the version identifier; tptacek
refers to the primitives and the separator strings; I consider the whole
thing.

Regardless, it is clear that there are numerous ways that can be backward
compatible to extend wireguard into v2. IIUC, the deliberate design decision
is that "we are not baking any specific one-true-way". It's not "not preparing
for the inevitability", it's "the way protocol agility has been done so far
has failed, we defer this decision closer to the time we need it".

~~~
dennisjac
Thanks for the pointer. I couldn't find any (semi-)official information about
this and seeing that the developers indeed care about this puts my concerns at
ease to some extent.

------
craftyguy
Previously on HN:

[https://news.ycombinator.com/item?id=16326438](https://news.ycombinator.com/item?id=16326438)

[https://news.ycombinator.com/item?id=15596963](https://news.ycombinator.com/item?id=15596963)

[https://news.ycombinator.com/item?id=17659983](https://news.ycombinator.com/item?id=17659983)

The last one highlighting the last blocker for any serious adoption.

------
tankfeeder
[https://bitbucket.org/mihailp/wireguard-
pil/src](https://bitbucket.org/mihailp/wireguard-pil/src)

------
Hnewswg1
Still awaiting for the official Windows client.........

------
pat2man
Looking at the design of WireGuard it seems relatively obvious. Is there a
reason it took this long to get such a basic solution?

~~~
orbital-decay
Simple is harder than complex, as always.

~~~
api
I really wish more people understood this. Over-engineering is the plague of
modern software.

