WireGuard: Next Generation Kernel Network Tunnel [pdf] • Hacker News Board

Re: WireGuard: Next Generation Kernel Network Tunnel [pdf]

#21

Post by zx2c4 » Tue, Aug 07, 2018, 6:55 AM UTC

dennisjac wrote: post #17

kamilner wrote: post #15

Earlier quoted context omitted.

There are 3 reserved bytes in each of the handshake messages [0] which I imagine would be used for this purpose. There's also a full byte for message type, of which I think only 0x1 through 0x4 are currently defined. [0] Page 10 onwards of https://www.wireguard.com/papers/wireguard.pdf

While this is a possibility it is still strange to not specify something like the protocol version intentionally. Even if in an updated implementation these fields would be used for something like that they still couldn't communicate properly with an older implementation which doesn't understand the new semantics of these fields. Also looking at the struct it seem the three bytes are only reserved in order to align t…

> If the authors had the intent

Fortunately I know exactly what I was thinking. Each message has an explicit type. The set of types exists in the first byte with the remaining three reserved for future additional use, perhaps for naming types. The cryptography is tied to the version by way the identifier and construction constants.

Re: WireGuard: Next Generation Kernel Network Tunnel [pdf]

#22

Post by zx2c4 » Tue, Aug 07, 2018, 6:58 AM UTC

beagle3 wrote: post #19

dennisjac wrote: post #14

Earlier quoted context omitted.

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.wiregua…

The discussion in 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 numerou…

I don't think there's any disagreement. Tom and I are both referring to the same things using slightly different words.

Re: WireGuard: Next Generation Kernel Network Tunnel [pdf]

#23

Post by zx2c4 » Tue, Aug 07, 2018, 7:05 AM UTC

dennisjac wrote: post #18

nickik wrote: post #16

Earlier quoted context omitted.

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.

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 vers…

> 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 Jason@zx2c4.com". 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]

#24

Post by dennisjac » Tue, Aug 07, 2018, 9:26 AM UTC

beagle3 wrote: post #19

dennisjac wrote: post #14

Earlier quoted context omitted.

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.wiregua…

The discussion in 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 numerou…

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.

Re: WireGuard: Next Generation Kernel Network Tunnel [pdf]

#25

Post by dennisjac » Tue, Aug 07, 2018, 9:42 AM UTC

zx2c4 wrote: post #23

dennisjac wrote: post #18

Earlier quoted context omitted.

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 vers…

> 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 Jason@zx2c4.com". It seems like this thread is going in circles based on incorrect information about how the thing actually…

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]

#26

Post by nostream » Tue, Aug 07, 2018, 10:12 AM UTC

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.