On Mon, 2018-08-13 at 10:02 -0700, Jason A. Donenfeld wrote: > > Could we please build planning for this crypto failure day into > > wireguard now rather than have to do it later? It doesn't need to > > be full cipher agility, it just needs to be the ability to handle > > multiple protocol versions ... two should do it because that gives > > a template to follow (and test version to try to find bugs in the > > implementation). It looks like the protocol could simply be updated > > to put the version into one (or more) of the three reserved bytes > > in the handshake headers, so perhaps doing this before they get > > used for something else would be a good first step? > > > > James > > > > > > Indeed the answer is in fact along the lines of what you've suggested > in your question: the protocol is very strictly versioned. This means > that while there intentionally isn't negotiation of ciphers -- > something historically very bug-prone -- there is ample room for > updating the protocol. This is enabled via 4 aspects of the protocol: > > - An explicit "identifier" string is hashed in as part of the first > step of cryptographic operations, containing a "v1" as well as the > protocol designer's email. > - An explicit "construction" string is hashed in as part of the first > step of cryptographic operations, containing the Noise handshake > pattern and a list of the cryptographic primitives used.
Any hash involving other parameters allows you to check for a version mismatch, but it's very hard for a flow classifier because you have to do the hash at the point you classify. If we're running concurrent versions we need an easy way to separate them. > - A type field at the beginning of each message. Newer message types > (corresponding with newer versions) can easily be introduced via this > field, and they can even coexist with older ones need be. > - Three unused reserved fields ready to be utilised in the event > they're needed. Either of these will work for easy classification. > In other words, there's ample room for such contingency measures > within the protocol. I have a preference for explicit versioning, having dealt with some protocol issues before. However, I'm much less concerned with *how* it's done than that it *be* done in the kernel patch so we can test out rolling the version number to change the algorithms in a backward compatible way, so lets pick one of the above and try it out. Regards, James
