4 ms·

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 f

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.

kamilner 8y ago
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 https://www.wireguard.com/papers/wireguard.pdf
- dennisjac 8y ago
  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 the following fields on 4-byte boundaries. If the authors had the intent to allow for some kind of asynchronous update path then surely this would be built explicitly into the protocol right from the start.
  - zx2c4 8y ago
    > 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.
nickik 8y ago
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.
- dennisjac 8y ago
  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.
  - beagle3 8y ago
    ... 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.
  - zx2c4 8y ago
    > 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.
    - 8y ago
beagle3 8y ago
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".
- zx2c4 8y ago
  I don't think there's any disagreement. Tom and I are both referring to the same things using slightly different words.
- dennisjac 8y ago
  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.

kamilner 8y ago

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 https://www.wireguard.com/papers/wireguard.pdf

dennisjac 8y ago
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 the following fields on 4-byte boundaries. If the authors had the intent to allow for some kind of asynchronous update path then surely this would be built explicitly into the protocol right from the start.
- zx2c4 8y ago
  > 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.

nickik 8y ago

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.

dennisjac 8y ago
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.
- beagle3 8y ago
  ... 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.
- zx2c4 8y ago
  > 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.
  - 8y ago

beagle3 8y ago

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".

zx2c4 8y ago
I don't think there's any disagreement. Tom and I are both referring to the same things using slightly different words.
dennisjac 8y ago
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.