Reflections on WireGuard Design Goals

[Brian Candler]

> For whatever reason, in the last several weeks, WireGuard been receiving a
> considerable amount of attention, and with that comes various parties
> interested in the project moving in this direction or in that direction. And
> more generally, over the last year or so, we've seen a decent amount of
> interest from different folks wanting to do different things with the project
> and with the protocol. This inevitably leads to the question: what do we
> actually want WireGuard to be, as a project, as a protocol, as a set of
> implementations, as a design methodology, and so forth? I've had a pretty
> clear idea about that, but I don't think I've ever tried to communicate
> aspects of it in this context, so I thought here I'd highlight two important
> design goals that motivate us.
Thanks for explaining the project background, and your very sensible 
goals of simplicity and robustness.  And thanks for releasing this 
excellent piece of software.

 From my point of view, the only thing which makes me uncomfortable 
about wireguard is the lack of any second authentication factor. Your 
private key is embedded in a plaintext file in your device (e.g. 
laptop), not even protected with a passphrase.  Anyone who gains access 
to that laptop is able to establish wireguard connections.

Of course, it can be argued that the laptop holds other information 
which is more valuable that the wireguard key, therefore you should 
concentrate on properly securing the laptop itself (*). Furthermore, to 
be able to talk to the wireguard kernel module you're already root, and 
therefore have all sorts of malicious options available to you. etc etc

But I'd feel a lot happier if a second level of authentication were 
required to establish a wireguard connection, if no packets had been 
flowing for more than a configurable amount of time - say, an hour. It 
would give some comfort around lost/stolen devices.

Whilst I appreciate that wireguard is symmetrical, a common use case is 
to have remote "clients" with a central "office".  I'm thinking about a 
hook whereby the "office" side could request extra authentication when 
required - e.g. if it sees a connection from a wireguard public key 
which has been idle for more than a configurable amount of time, then it 
sends a challenge which requires (e.g.) a Yubikey to complete.  I 
appreciate that it's not going to be straightforward, requiring the 
kernel module to talk to userland components at both ends.

In the absence of that, it would be nice if the private key which is 
stored on the laptop were encrypted with a passphrase.  Simplest option 
may be to extend wg-quick so that the entire config file can be 
pgp-encrypted.

Regards,

Brian.

(*) You could make a similar argument for ssh keys or pgp keys, saying 
there's no need to protect them with a passphrase if the host they are 
stored on is properly secured.  I think many people would disagree.