Re: [PATCH v1 0/3] WireGuard: Secure Network Tunnel

Re: [PATCH v1 0/3] WireGuard: Secure Network Tunnel

[James Bottomley]

> Ample information, including documentation, installation
> instructions,
> and project details, is available at:
> 
>   * https://www.wireguard.com/
>   * https://www.wireguard.com/papers/wireguard.pdf

In your paper you say this:

> Finally, WireGuard is cryptographically opinionated. It intentionally
> lacks cipher and protocol agility. If
> holes are found in the underlying primitives, all endpoints will be
> required to update.

The only thing that's certain (beyond death and taxes) is that your
crypto choice will one day need updating; either in response to an
urgent CVE because an algorithm is compromised or in response to a less
urgent one because it is deprecated.  Assuming wireguard is reasonably
successful we'll have a large ecosystem dependent on it.  On this day,
we're going to have the choice of either breaking the entire ecosystem
by rolling out a change that can't connect to lower protocol versions
or trying to wedge version agility into wireguard in a hurry.  The
former is too awful to contemplate because of the almost universal
ecosystem breakage it would cause and the latter is going to lead to
additional bugs because people in a hurry aren't as careful as they
should be.

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

Re: [PATCH v1 0/3] WireGuard: Secure Network Tunnel

[Willy Tarreau]

On Mon, Aug 13, 2018 at 08:40:11AM -0700, James Bottomley 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's also what provides a *real* upgrade path to future versions :
before deploying you need something which works, and the only way to
get something working at a large scale is to have early adopters. Those
willing to deploy a beta version will not do it if it requires to lose
all their users and possibly to make rollbacks impossible. At least for
this it's important to support an optionnal new version on top of the
existing one (i.e. prod + beta together).

Cheers,
Willy

Re: [PATCH v1 0/3] WireGuard: Secure Network Tunnel

[Jason A. Donenfeld]

Hi James,

On 8/13/18, James Bottomley <James.Bottomley@hansenpartnership.com> wrote:
>> Ample information, including documentation, installation
>> instructions,
>> and project details, is available at:
>>
>>   * https://www.wireguard.com/
>>   * https://www.wireguard.com/papers/wireguard.pdf
>
> In your paper you say this:
>
>> Finally, WireGuard is cryptographically opinionated. It intentionally
>> lacks cipher and protocol agility. If
>> holes are found in the underlying primitives, all endpoints will be
>> required to update.
>
> The only thing that's certain (beyond death and taxes) is that your
> crypto choice will one day need updating; either in response to an
> urgent CVE because an algorithm is compromised or in response to a less
> urgent one because it is deprecated.  Assuming wireguard is reasonably
> successful we'll have a large ecosystem dependent on it.  On this day,
> we're going to have the choice of either breaking the entire ecosystem
> by rolling out a change that can't connect to lower protocol versions
> or trying to wedge version agility into wireguard in a hurry.  The
> former is too awful to contemplate because of the almost universal
> ecosystem breakage it would cause and the latter is going to lead to
> additional bugs because people in a hurry aren't as careful as they
> should be.
>
> 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.
- 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.

In other words, there's ample room for such contingency measures
within the protocol.

Jason

Re: [PATCH v1 0/3] WireGuard: Secure Network Tunnel

[James Bottomley]

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

Re: [PATCH v1 0/3] WireGuard: Secure Network Tunnel

[Jason A. Donenfeld]

> but it's very hard for a flow classifier because you have to

The construction and identifier strings might not obviously help with
the extremely narrow idea you've brought up, but it is very important
for safely introducing additional versions. Namely, it prevents
against cross-protocol key reuse attacks and type confusion bugs. So
don't be too quick to dismiss the importance of these for
accomplishing what we're after.

> so lets pick one of the above and try it out.

We have, multiple times, and it's absolutely trivial to do and works
well. The exact thing you're concerned about has already been
researched and worked with on live systems quite a bit over the last 3
years, and it works in a pretty straight forward way. I'm not sure
there's much more to add here: the thing you want is already there and
has been tested extensively. At this point the "pick one and let's try
it out!" is an old story, and the focus now is on making sure the code
quality and netdev api usage is correct for merging

Re: [PATCH v1 0/3] WireGuard: Secure Network Tunnel

[James Bottomley]

On Mon, 2018-08-13 at 10:55 -0700, Jason A. Donenfeld wrote:
> > but it's very hard for a flow classifier because you have to
> 
> The construction and identifier strings might not obviously help with
> the extremely narrow idea you've brought up, but it is very important
> for safely introducing additional versions. Namely, it prevents
> against cross-protocol key reuse attacks and type confusion bugs. So
> don't be too quick to dismiss the importance of these for
> accomplishing what we're after.

I'm not saying a hash check isn't important for safety; I'm saying that
if you only have a hash of a dynamic part plus the protocol identifier
to go on it makes far more work for the flow classifier.  You can see
this easily if you contemplate the idea that the hash might be the
algorithm being changed.

> > so lets pick one of the above and try it out.
> 
> We have, multiple times, and it's absolutely trivial to do and works
> well. The exact thing you're concerned about has already been
> researched and worked with on live systems quite a bit over the last
> 3 years, and it works in a pretty straight forward way. I'm not sure
> there's much more to add here: the thing you want is already there
> and has been tested extensively. At this point the "pick one and
> let's try it out!" is an old story, and the focus now is on making
> sure the code quality and netdev api usage is correct for merging

Great, thanks, I'll look forward to seeing it in v2 then.

James