Re: Reflections on WireGuard Design Goals

Re: Reflections on WireGuard Design Goals

[Brian Candler]

> For whatever reason, in the last several weeks, WireGuard been receivin=
g 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 p=
roject
> and with the protocol. This inevitably leads to the question: what do w=
e
> 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 pret=
ty
> 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 impo=
rtant
> design goals that motivate us.
Thanks for explaining the project background, and your very sensible=20
goals of simplicity and robustness.=C2=A0 And thanks for releasing this=20
excellent piece of software.

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

Of course, it can be argued that the laptop holds other information=20
which is more valuable that the wireguard key, therefore you should=20
concentrate on properly securing the laptop itself (*). Furthermore, to=20
be able to talk to the wireguard kernel module you're already root, and=20
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=20
required to establish a wireguard connection, if no packets had been=20
flowing for more than a configurable amount of time - say, an hour. It=20
would give some comfort around lost/stolen devices.

Whilst I appreciate that wireguard is symmetrical, a common use case is=20
to have remote "clients" with a central "office".=C2=A0 I'm thinking abou=
t a=20
hook whereby the "office" side could request extra authentication when=20
required - e.g. if it sees a connection from a wireguard public key=20
which has been idle for more than a configurable amount of time, then it=20
sends a challenge which requires (e.g.) a Yubikey to complete.=C2=A0 I=20
appreciate that it's not going to be straightforward, requiring the=20
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=20
stored on the laptop were encrypted with a passphrase.=C2=A0 Simplest opt=
ion=20
may be to extend wg-quick so that the entire config file can be=20
pgp-encrypted.

Regards,

Brian.

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

Re: Reflections on WireGuard Design Goals

[Matthias Urlichs]

[-- Attachment #1.1: Type: text/plain, Size: 1363 bytes --]

On 10.08.2018 15:35, Brian Candler wrote:
> 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. 

It's reasonably easy to add that as a service on top of Wireguard, once
you have an authenticated connection. The office can easily talk to an
app on the mobile device when it notices a re-awakened stale connection
(triggered by a firewall logging rule, for instance), exchange whatever
crypto it requires, and only then allow packets other than those
required for authenticating to flow through the interface (another
simple firewall rule change).

Adding a feature like this to the WG kernel itself would not be any more
secure (and indeed add a significant amount of complexity which may
exhibit exploitable bugs). It would also unnecessarily enshrine a
particular 2FA scheme into wireguard.

-- 
-- Matthias Urlichs



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Reflections on WireGuard Design Goals

[Kalin KOZHUHAROV]

[-- Attachment #1: Type: text/plain, Size: 3108 bytes --]

Please excuse my brevity, phone typing here...

On Fri, 10 Aug 2018, 16:36 Brian Candler, <b.candler@pobox.com> wrote:

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

Not always. You can generate it on the fly (say 1st boot, no config file),
distribute it and be done. Or you can choose to protect it (e.g. pgp), may
be even store it in a HSM. Or throw it (keep in RAM) and regenerate, if
needed.

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.
>
And what do we do (count or not) keepalive traffic?

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.
>
That is way overcomplicated...
And how did you solve your key distribution in such scenario BTW? (hint:
the functionality you request is part of key handling, i.e. NOT part of wg,
AFAIK). The office end can expire any user key and request sidechannel
(additional, 2FA or more) authentication via the established link. Who says
wg tunnel should be to the network core? Use a standard firewall, plug a
RADIUS even, or script your way on top of wg. Feel free to provide a clean
interface to wg and documentation and people who want that functionality
will use the code. Is there anything (e.g. design-level) that prevents
that? Or functionality that is lacking at the core?

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

Now that also is not 2FA, and yes it should be a few lines of scripting.

Kalin.

[-- Attachment #2: Type: text/html, Size: 4434 bytes --]

Re: Reflections on WireGuard Design Goals

[Eisfunke]

Hello together,

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

one can already do that via the wg-quick PostUp hook, check out the Arch Linux 
wiki:
https://wiki.archlinux.org/index.php/
WireGuard#Store_private_keys_in_encrypted_form

The example is using pass, switching it for direct GPG (or keepassxc or 
anything, really) should be easily possible.

Considering that possibility, I don't think adding GnuPG directly into 
Wireguard would be a good idea. It would just add complexity for little to no 
benefit.

Greetings,
NIcolas Lenz

Re: Reflections on WireGuard Design Goals

[Konstantin Ryabitsev]

[-- Attachment #1: Type: text/plain, Size: 2842 bytes --]

On Fri, Aug 10, 2018 at 02:35:14PM +0100, Brian Candler wrote:
>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.

I think one way of solving this is teaching the client-side tools to 
hook into the TPM. We still grab the key and store it in memory (as 
opposed to using TPM's crypto processing directly), but at least this 
way it's not lying around on disk somewhere, and it doesn't require 
changing anything about the protocol. I am hoping to hit up James 
Bottomley about it when I next see him -- he's already written quite a 
few tools that use TPM, including teaching GnuPG how to use it. :)

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

I believe this is orthogonal to the design of the protocol, which is 
supposed to behave in a "stateless" fashion and resume transparently 
after even prolonged downtimes. We use 2-factor authentication with 
OpenVPN, and one of the most annoying aspects about it is the fact that 
you have to manually re-auth after each VPN blip. If you don't do it 
quickly enough, all your sessions get reset -- most horrible experience 
if you are hoping your ssh connection to a server doesn't get severed in 
the middle of a yum update.

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

I think Wireguard's primary strength is its resilience to network blips 
and fast operation. We intend to use it for site-to-site connectivity 
across disjointed infrastructure where it will certainly operate much 
smoother than OpenVPN or ipsec. For admin-to-site connections we will 
continue to use OpenVPN or some combination thereof, until we figure out 
a straightforward way of "upgrading" access level of a wireguard 
connection. I suspect this is fairly easy with iptables and fwmark, but 
I need to test and streamline it.

-K

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Reflections on WireGuard Design Goals

[Roman Mamedov]

On Fri, 10 Aug 2018 14:35:14 +0100
Brian Candler <b.candler@pobox.com> wrote:

>  From my point of view, the only thing which makes me uncomfortable=20
> about wireguard is the lack of any second authentication factor. Your=20
> private key is embedded in a plaintext file in your device (e.g.=20
> laptop), not even protected with a passphrase.=C2=A0 Anyone who gains acc=
ess=20
> to that laptop is able to establish wireguard connections.
>=20
> Of course, it can be argued that the laptop holds other information=20
> which is more valuable that the wireguard key, therefore you should=20
> concentrate on properly securing the laptop itself (*). Furthermore, to=20
> be able to talk to the wireguard kernel module you're already root, and=20
> therefore have all sorts of malicious options available to you. etc etc
>=20
> But I'd feel a lot happier if a second level of authentication were=20
> required to establish a wireguard connection, if no packets had been=20
> flowing for more than a configurable amount of time - say, an hour. It=20
> would give some comfort around lost/stolen devices.

Couldn't you just encrypt your home directory? Or even the root FS entirely.
Either of those should be a must on a portable device storing valuable
information.

--=20
With respect,
Roman

Re: Reflections on WireGuard Design Goals

[Brian Candler]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

On 10/08/2018 16:03, Roman Mamedov wrote:
>> 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.
> Couldn't you just encrypt your home directory? Or even the root FS entirely.
> Either of those should be a must on a portable device storing valuable
> information.

But by analogy, would you say that SSH keys and PGP keys don't need 
protection by a passphrase?


[-- Attachment #2: Type: text/html, Size: 1007 bytes --]

Re: Reflections on WireGuard Design Goals

[Kalin KOZHUHAROV]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

On Fri, 10 Aug 2018, 19:04 Brian Candler, <b.candler@pobox.com> wrote:

> On 10/08/2018 16:03, Roman Mamedov wrote:
>
> 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.
>
> Couldn't you just encrypt your home directory? Or even the root FS entirely.
> Either of those should be a must on a portable device storing valuable
> information.
>
> But by analogy, would you say that SSH keys and PGP keys don't need
> protection by a passphrase?
>
Yes, I will say so. I (almost) never use it, it is either too unsecure yet
cumbersome, so I use separate devices (nFA), encrypted FS, etc. where
needed. Or nothing at all.

Kalin.

[-- Attachment #2: Type: text/html, Size: 1494 bytes --]

Re: Reflections on WireGuard Design Goals

[jungle Boogie]

On 10 August 2018 at 09:03, Brian Candler <b.candler@pobox.com> wrote:
> On 10/08/2018 16:03, Roman Mamedov wrote:
>
> 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.
>
> Couldn't you just encrypt your home directory? Or even the root FS entirely.
> Either of those should be a must on a portable device storing valuable
> information.
>
> But by analogy, would you say that SSH keys and PGP keys don't need
> protection by a passphrase?
>

If someone already has my ssh key, I'd revoke it - regardless if they
had the password or not.
Same with the WG key - shutdown the tunnel, remove the affected peer
and start it back up.

Re: Reflections on WireGuard Design Goals

[Aaron Jones]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/08/18 16:40, jungle Boogie wrote:
> If someone already has my ssh key, I'd revoke it - regardless if
> they had the password or not. Same with the WG key - shutdown the
> tunnel, remove the affected peer and start it back up.

No need to interrupt the tunnel.

# wg set <interface> peer <publickey> remove

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAlttx3oACgkQivBzdIir
MBJTWw//dL9Te/8nfr18EQQEmWXRqgS7A6QrXh5lrAjTlHAHuzbfM2sp+mt5ML50
fmEHlsVHZqM4rG4l1+KiSrUb6n7hlzoCO2bwh36U/tdysXgf20vM9XN4vyhvWMbN
eOB6CNHfso02uMzx4TCAaK2ZcWnsqh1LvXceVwMQdJ6+E2FDpu637TYEiWJyIDPv
u/q5Qq+qZspFiqDTpAJ/scdLq+4AxnzeELs/OblfRYbvE+Hkc9VsunxXJImXvcKx
cN1NldPxwR+a4fWTvKgIqVReIKEggDl4OzYZk+wipFLRwQWASYW3aYQ+UeQEaUHa
TQqkfZ6PqvivKLPC+Ih3DVHYd4Xa4t+zC/gVtQYgAauhqcqtpH1Y0ZISohIR9x/t
2GMxOZPg7Q6x05qf0bKdWPgdH+lcENW1HYEhj/cWrKaCAoKgKOnGsfgUNEdvRXMb
i/RiLnJ5NH07sg4C/QRdVOXxx/TwBoEZPvgXUsxteadBc77LLOR4ERNVZ4zQrvhv
JhhLeckOL9dmywPuvvO4sc/cOZCvb2kaYSDD1Tn4iJaqWZwWdA8HNnGyBnl14mMF
9ER5qzSA0L9QRDXhyBkv1+ekDmshBnpyj6PN7kBJ5cl9WVZXLjIsUWcte9YXfbIM
MqwqhoGBdF0n5T41OP0zt4vT1DWLF9pGsOiUUq7GahpIXp1mPMo=
=T+rR
-----END PGP SIGNATURE-----

Re: Reflections on WireGuard Design Goals

[jungle Boogie]

>
> On 10/08/18 16:40, jungle Boogie wrote:
>> If someone already has my ssh key, I'd revoke it - regardless if
>> they had the password or not. Same with the WG key - shutdown the
>> tunnel, remove the affected peer and start it back up.
>
> No need to interrupt the tunnel.
>
> # wg set <interface> peer <publickey> remove
>

Dang, that's cool! That's for the info.

Re: Reflections on WireGuard Design Goals

[em12345]

Hi,

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

Most VPN authentications are just authorizing the machine and not the
user sitting in front of that machine.

> 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,

No matter how much keys, passwords or tokens have to be entered by the
user sitting in front of that machine, any other user already on that
machine, will gain sooner or later access to the tunnel. This user or
attacker doesn't even need to see/know wireguard's private key nor does
the attacker need root access. Think of a second user logged in on that
machine.

It is definitely a bad idea to assume that the tunnel traffic of one
"client" (in terms of wg's client key pair) comes from a specific user.
Which also means that even multi factor VPN authentication still require
all services inside the tunnel to ask for user authentication.


Emmanuel

Re: Reflections on WireGuard Design Goals

[Reuben Martin]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

On Fri, Aug 10, 2018, 3:16 PM em12345 <em12345@web.de> wrote:

> Hi,
>
> > 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.
>
> Most VPN authentications are just authorizing the machine and not the
> user sitting in front of that machine.
>
> > 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,
>
> No matter how much keys, passwords or tokens have to be entered by the
> user sitting in front of that machine, any other user already on that
> machine, will gain sooner or later access to the tunnel. This user or
> attacker doesn't even need to see/know wireguard's private key nor does
> the attacker need root access. Think of a second user logged in on that
> machine.
>
> It is definitely a bad idea to assume that the tunnel traffic of one
> "client" (in terms of wg's client key pair) comes from a specific user.
> Which also means that even multi factor VPN authentication still require
> all services inside the tunnel to ask for user authentication.
>

It should me noted that it is possible to isolate the VPN access to a
specific user if you assign login sessions to isolated network namespaces
and place the wireguard interface within the user's namespace.

-Reuben

>

[-- Attachment #2: Type: text/html, Size: 2304 bytes --]

Re: Reflections on WireGuard Design Goals

[Jason A. Donenfeld]

On Fri, Aug 10, 2018 at 6:35 AM Brian Candler <b.candler@pobox.com> wrote:
> But I'd feel a lot happier if a second level of authentication were
> required to establish a wireguard connection

I think that given the WireGuard building block, it's certainly
possible to build a 2FA framework around it. And I do generally like
2FA and short-lived credentials and such. Probably after getting the
implementations buttoned up -- kernel mainline, windows, etc -- I'll
turn a bit of attention to expanding tooling and full packages around
the simple wg0 interface.

Jason

Re: Reflections on WireGuard Design Goals

[Luiz Angelo Daros de Luca]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

> I think that given the WireGuard building block, it's certainly
> possible to build a 2FA framework around it.
>

I see these wireguard extra features just like dhcp is. Nobody thinks about
implementing dhcp inside kernel or even iproute tools.

+1 for 2FA and +1 for a service that share peer info, allowing a mesh vpn

> --

Luiz Angelo Daros de Luca
luizluca@gmail.com

[-- Attachment #2: Type: text/html, Size: 892 bytes --]

Re: Reflections on WireGuard Design Goals

[Aaron Jones]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/08/18 22:52, Luiz Angelo Daros de Luca wrote:
> I see these wireguard extra features just like dhcp is. Nobody
> thinks about implementing dhcp inside kernel or even iproute
> tools.

The Linux kernel has a (minimal, non-configurable) DHCP client already
(used for rootfs on NFS without an initramfs, among other things).

CONFIG_IP_PNP_BOOTP=y

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAltvfB4ACgkQivBzdIir
MBLldA//aCK1DHoew8joweZkI2coLZjolMqPActFDTtDkIXAka3guJjh2zVDCxVF
45AdF1Xv7jhmuDB4emCgH6ANk0vPDAHvs6SBYYZgHvvHdNbBzmM9FqJFk01KHUkl
LhPVCjR9T9EMNifoP5EI1R3YTpoAQbUpaJJ9K12rumdGMelpVU7qg7hW7VkscwAq
WtmN/wuD3w3mZKH+TvtlT409JefvocvE9kA7NUXWOZ9Bxxj3pEJIVTmquE6MS4rm
zHcQ7hY3JR7cPg4Imc0FHuyvbU55R2AnU9+00+dTUISlBT9k2pneIw4EhW0WSHLK
uXXplZfpwV9WSiI/n1dXX1RdRc/42U6LsD4ZLPr6uxoULyeM0ahW7P2+Zq7+yt34
gEDjwTdLSLQYpLEWhAZ4q6fBLGamZHqXgLXTtioWrIqr5eaScYJcINNjsnAEa8Kz
3Oo5HOxvJvEMyDz35M+04ugAbjW5LHiqWsOoWfX0A2XfDPt9mnTuiPXrGSLEPWdh
5OvOsPAmda4/CbJo83cRHqwhsOvoxIJX5+Ewx8giyLZ4lWIGum57wD6n6ZaUVsHZ
9OXA8f7LZdkxKZ/QSFi7HN9S7SRdkCbJB9E0L96AAVhPGbZuXkGavN5sIOA3fd7Y
CWMCI3Y+x675gtYTpVooR+P1fTWgBAHOHuVFeU8e+LSHwhMallc=
=OY67
-----END PGP SIGNATURE-----

Re: Reflections on WireGuard Design Goals

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

On Sat, Aug 11, 2018, 17:15 Aaron Jones <aaronmdjones@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 11/08/18 22:52, Luiz Angelo Daros de Luca wrote:
> > I see these wireguard extra features just like dhcp is. Nobody
> > thinks about implementing dhcp inside kernel or even iproute
> > tools.
>
> The Linux kernel has a (minimal, non-configurable) DHCP client already
> (used for rootfs on NFS without an initramfs, among other things).
>
> CONFIG_IP_PNP_BOOTP=y
>

This is in fact true, but I'm not sure we're planning on following suite
with that kind of thing in kernel space for WireGuard...




> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAltvfB4ACgkQivBzdIir
> MBLldA//aCK1DHoew8joweZkI2coLZjolMqPActFDTtDkIXAka3guJjh2zVDCxVF
> 45AdF1Xv7jhmuDB4emCgH6ANk0vPDAHvs6SBYYZgHvvHdNbBzmM9FqJFk01KHUkl
> LhPVCjR9T9EMNifoP5EI1R3YTpoAQbUpaJJ9K12rumdGMelpVU7qg7hW7VkscwAq
> WtmN/wuD3w3mZKH+TvtlT409JefvocvE9kA7NUXWOZ9Bxxj3pEJIVTmquE6MS4rm
> zHcQ7hY3JR7cPg4Imc0FHuyvbU55R2AnU9+00+dTUISlBT9k2pneIw4EhW0WSHLK
> uXXplZfpwV9WSiI/n1dXX1RdRc/42U6LsD4ZLPr6uxoULyeM0ahW7P2+Zq7+yt34
> gEDjwTdLSLQYpLEWhAZ4q6fBLGamZHqXgLXTtioWrIqr5eaScYJcINNjsnAEa8Kz
> 3Oo5HOxvJvEMyDz35M+04ugAbjW5LHiqWsOoWfX0A2XfDPt9mnTuiPXrGSLEPWdh
> 5OvOsPAmda4/CbJo83cRHqwhsOvoxIJX5+Ewx8giyLZ4lWIGum57wD6n6ZaUVsHZ
> 9OXA8f7LZdkxKZ/QSFi7HN9S7SRdkCbJB9E0L96AAVhPGbZuXkGavN5sIOA3fd7Y
> CWMCI3Y+x675gtYTpVooR+P1fTWgBAHOHuVFeU8e+LSHwhMallc=
> =OY67
> -----END PGP SIGNATURE-----
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #2: Type: text/html, Size: 2670 bytes --]

Re: Reflections on WireGuard Design Goals

[Aaron Jones]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/08/18 00:46, Jason A. Donenfeld wrote:
> This is in fact true, but I'm not sure we're planning on following
> suite with that kind of thing in kernel space for WireGuard...

Indeed. :)

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAltviFMACgkQivBzdIir
MBIolg//Tbt8zZy/nqtY3njasE6n5OXGs/qSP2GZbJSB4Ieyi1TZfJRumJTNfKSM
YLHZmaju+KZO85f6fwj+wqe89swD6WD0mGPKpCwhc+3j403YyT/ggp9uyqSTP78H
D9KEIFnX50mtwnj6cWzY3U9H3V0katWRms0P65U90kJF1Fb91EeAplIZnHlIygwa
m9+lBB8oJ+dXgkNmjaajI23idYV1qFVw8z9TR22lyXjAWsK0evJ1rcpKtuiIn9FX
3eZ+0QBNF5lCDVyWKl8Y04rattFde3jWs9AAzDPP4nv8GJqo9Jpponzy8jXSFxu5
CwvDShMS3ytWIO+zmSskkcZmh7h00puDhLzVRXneTfE7kbIyT31xQsH4sS2LQ4cY
4W3RoIYY7DnJW1IEaUYa3FAVWjW7XNZUUAU0fNcYJHVmqrPtDJYm692OEv8Hou3+
yn2YjaXaQPXPFqztLrExqDQL2RS4evSx0TRgTBp39ya43MDILM+EG3j04G4ibuyV
EeDykMd6KY3h3fVsxhQBE0lryDgS2QHZsr+6ziwFzP8e0Pmy6vU32iNEw1MhEItX
4ffufoanwXO7UKPpcoHCZDOzcxbo7DUDt4EEQpLYSOr4fXqcHfxY6dhT1vetRA0U
rnVnX2/tkrDUKJcUI8d7DV1WJqQQUBWdNLzZXWuYcAE08U74U+I=
=4Yzj
-----END PGP SIGNATURE-----

Re: Reflections on WireGuard Design Goals

[nicolas prochazka]

hello,
just to say you, as a simple end user
we are using wireguard since one year for our product,
we have 10K tunnels deployed ,
wireguard is perfect for us, very simple, we can develop our specific
code on top of if ( key management , ....)
so +1 for jason vision
thanks for this piece of code
Regards,
Nicolas

Le jeu. 9 ao=C3=BBt 2018 =C3=A0 23:52, Jason A. Donenfeld <Jason@zx2c4.com>=
 a =C3=A9crit :
>
> Hey list,
>
> 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 pro=
ject
> 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 import=
ant
> design goals that motivate us.
>
> Firstly, WireGuard intends on continuing to have a minimal core, without =
a lot
> of options and wild features and support for weird networking paradigms. =
Sure,
> we want the core to be sufficiently flexible that you can build interesti=
ng
> and complex things on top of it, but we don't want WireGuard itself to be
> complicated. We enjoy our small understandable configuration files, an
> interface that appears to be mostly stateless, and general ease of use. E=
ven
> from a cryptography and implementation perspective, the protocol is desig=
ned
> to be implementable using simple algorithms and coding techniques.
>
> With that kind of minimalism naturally comes the temptation to add things=
.
> Simply from the perspective of an interested engineer, it's appealing to
> extend and hack on small manageable codebases and projects, since adding =
a
> single feature here or there just isn't that hard. And after all, if you'=
re
> *just* adding *one* feature, it's only one, and that's not so bad, right?=
 And
> what about one more? This kind of temptation applies equally to features
> inside implementations as it does to features inside the protocol. And I =
think
> this temptation is a little bit dangerous, both because it's an obvious
> slippery slope to bloat ("just one more feature can't hurt, right guys?")=
, and
> because while individual features or protocol enhancements might be well
> thought-out, it's often hard to think through them in the context of a fu=
ller
> system.
>
> Secondly, WireGuard is engineered slowly and carefully. It is a conservat=
ive
> project. Programming is fun, and so I understand the appeal to, "move fas=
t and
> break things," or to ship new code hastily. Personally I've written plent=
y of
> such codebases, and that's usually fun and exciting. Except WireGuard is
> deeply security-oriented. Of course there will inevitably be scary bugs w=
e
> weren't able to prevent, but we're moving slow and carefully to try to
> mitigate those to the fullest extent we can. We want each of the
> implementations released by the WireGuard project to be secure, high assu=
rance
> software.
>
> This means that although you can probably get something mostly "working" =
in a
> fairly short amount of time (an initial version of WireGuard took me
> essentially a weekend), we're trying very hard not to throw junk over the
> fence. Rather, we're doing pretty regular code reviews and have received =
some
> great feedback from some scary-talented security researchers, and we expe=
ct
> for this to continue. But indeed not all programmers share this perspecti=
ve =E2=80=93
> for a wide variety of motivations, both benign and opportunistic =E2=80=
=93 and so we
> definitely will (and have, in fact, already) see folks making things rela=
ted
> to WireGuard who don't share this type of methodology.
>
> Now I don't think these two motivating principles are particularly unique=
 or
> innovative. Other security-focused projects, like OpenBSD for example, se=
em to
> be made of a somewhat similar mold. But these also certainly are not the
> _norm_ for most projects out there. And as WireGuard accelerates in usage=
, I
> expect we'll be facing this from a few angles:
>
> - Attempts at commercialization: There are many businesses who want to em=
brace
>   WireGuard and extend it in some particular direction or another, in ord=
er to
>   build products or sell services or the usual array of business
>   opportunities. Engineers working in these contexts often times are temp=
ted
>   to extend minimal things in grotesque ways, and to push them to market =
with
>   deadlines unfavorable to high assurance methodologies. It's naturally a=
nd
>   understandably in the interest of businesses to attempt to steer the
>   WireGuard project in directions aligned with their goals, or even direc=
tly
>   hire WireGuard developers away from an independent perspective working =
on
>   the open source project. This is pretty commonplace with open source
>   projects, and while sometimes everyone's interests align perfectly, it'=
s
>   easy to loose sight of the broader project goal; in particular, the goa=
l of
>   minimalism in particular is easy to leave by the wayside.
>
> - Folks who want their own corner of the Internet: We've already seen thi=
s
>   with a project, and as things accelerate, we'll probably also see it wi=
th
>   others. It's fun to run a project, and some people want to start with
>   WireGuard (and even our webpage design) but then spin it into all sorts=
 of
>   new clever and creative things, extending the protocol, adding features=
,
>   shipping code hastily, with the explicit caveat of not working within t=
he
>   WireGuard project or sticking with our design goals. Some folks simply
>   aren't interested in joining community projects. While I understand the=
 fun
>   and motivation of having your own corner, depending on the scale, I thi=
nk
>   ultimately it's harmful to users and harmful to the project as a whole.=
 I
>   also understand that splintering projects might aid in creating commerc=
ial
>   opportunities too, but again, I think it is overall harmful to the
>   ecosystem, whether open source or proprietary. I should  mention that T=
he
>   WireGuard project remains open to all sorts of development and develope=
rs
>   who would like to join in, in any capacity, and indeed we're quite eage=
r to
>   continue to share or hand off maintenance burden to others. We're also
>   willing and interested to work hand-in-hand with other open source proj=
ects
>   that share our design goals and methodologies.
>
> - The N+1 protocol: https://xkcd.com/927/ might just be a part of life. I
>   expect we'll be seeing a proliferation of Noise-based VPN protocols,
>   tailored for different use cases and environments, with differing secur=
ity
>   properties and attack surfaces. Designing protocols always involves
>   trade-offs, and there are always interesting arguments for different
>   trade-offs, and I wouldn't be surprised if we see some more WireGuard-l=
ike
>   things come out. Perhaps someday down the line after years of observati=
on,
>   there will even be improvements made for a new WireGuard protocol,
>   incorporating the rejuvenated research that's now being put into these =
types
>   of settings. Or not. But maybe. But either way, it seems likely there w=
ill
>   be various N+1 protocol proposals and implementations, because people
>   apparently like to make things; see XKCD.
>
> So, if WireGuard remains a small niche project, we'll keep on keeping on
> quietly and surely as ever. But should things continue to grow in usage a=
s
> we're seeing now, expect to see the various temptations proliferate. But
> regardless, I certainly intend to keep WireGuard true to our design goals=
 =E2=80=93 of
> minimalism, of security conservatism =E2=80=93 and I'll be working hard t=
o see that
> through.
>
> I should also reiterate that our doors remain very open to open source
> developers and projects who wish to join the work we're doing.
>
> Regards,
> Jason
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

Reflections on WireGuard Design Goals

[Jason A. Donenfeld]

Hey list,

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. An=
d
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 proje=
ct
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 importan=
t
design goals that motivate us.

Firstly, WireGuard intends on continuing to have a minimal core, without a =
lot
of options and wild features and support for weird networking paradigms. Su=
re,
we want the core to be sufficiently flexible that you can build interesting
and complex things on top of it, but we don't want WireGuard itself to be
complicated. We enjoy our small understandable configuration files, an
interface that appears to be mostly stateless, and general ease of use. Eve=
n
from a cryptography and implementation perspective, the protocol is designe=
d
to be implementable using simple algorithms and coding techniques.

With that kind of minimalism naturally comes the temptation to add things.
Simply from the perspective of an interested engineer, it's appealing to
extend and hack on small manageable codebases and projects, since adding a
single feature here or there just isn't that hard. And after all, if you're
*just* adding *one* feature, it's only one, and that's not so bad, right? A=
nd
what about one more? This kind of temptation applies equally to features
inside implementations as it does to features inside the protocol. And I th=
ink
this temptation is a little bit dangerous, both because it's an obvious
slippery slope to bloat ("just one more feature can't hurt, right guys?"), =
and
because while individual features or protocol enhancements might be well
thought-out, it's often hard to think through them in the context of a full=
er
system.

Secondly, WireGuard is engineered slowly and carefully. It is a conservativ=
e
project. Programming is fun, and so I understand the appeal to, "move fast =
and
break things," or to ship new code hastily. Personally I've written plenty =
of
such codebases, and that's usually fun and exciting. Except WireGuard is
deeply security-oriented. Of course there will inevitably be scary bugs we
weren't able to prevent, but we're moving slow and carefully to try to
mitigate those to the fullest extent we can. We want each of the
implementations released by the WireGuard project to be secure, high assura=
nce
software.

This means that although you can probably get something mostly "working" in=
 a
fairly short amount of time (an initial version of WireGuard took me
essentially a weekend), we're trying very hard not to throw junk over the
fence. Rather, we're doing pretty regular code reviews and have received so=
me
great feedback from some scary-talented security researchers, and we expect
for this to continue. But indeed not all programmers share this perspective=
 =E2=80=93
for a wide variety of motivations, both benign and opportunistic =E2=80=93 =
and so we
definitely will (and have, in fact, already) see folks making things relate=
d
to WireGuard who don't share this type of methodology.

Now I don't think these two motivating principles are particularly unique o=
r
innovative. Other security-focused projects, like OpenBSD for example, seem=
 to
be made of a somewhat similar mold. But these also certainly are not the
_norm_ for most projects out there. And as WireGuard accelerates in usage, =
I
expect we'll be facing this from a few angles:

- Attempts at commercialization: There are many businesses who want to embr=
ace
  WireGuard and extend it in some particular direction or another, in order=
 to
  build products or sell services or the usual array of business
  opportunities. Engineers working in these contexts often times are tempte=
d
  to extend minimal things in grotesque ways, and to push them to market wi=
th
  deadlines unfavorable to high assurance methodologies. It's naturally and
  understandably in the interest of businesses to attempt to steer the
  WireGuard project in directions aligned with their goals, or even directl=
y
  hire WireGuard developers away from an independent perspective working on
  the open source project. This is pretty commonplace with open source
  projects, and while sometimes everyone's interests align perfectly, it's
  easy to loose sight of the broader project goal; in particular, the goal =
of
  minimalism in particular is easy to leave by the wayside.

- Folks who want their own corner of the Internet: We've already seen this
  with a project, and as things accelerate, we'll probably also see it with
  others. It's fun to run a project, and some people want to start with
  WireGuard (and even our webpage design) but then spin it into all sorts o=
f
  new clever and creative things, extending the protocol, adding features,
  shipping code hastily, with the explicit caveat of not working within the
  WireGuard project or sticking with our design goals. Some folks simply
  aren't interested in joining community projects. While I understand the f=
un
  and motivation of having your own corner, depending on the scale, I think
  ultimately it's harmful to users and harmful to the project as a whole. I
  also understand that splintering projects might aid in creating commercia=
l
  opportunities too, but again, I think it is overall harmful to the
  ecosystem, whether open source or proprietary. I should  mention that The
  WireGuard project remains open to all sorts of development and developers
  who would like to join in, in any capacity, and indeed we're quite eager =
to
  continue to share or hand off maintenance burden to others. We're also
  willing and interested to work hand-in-hand with other open source projec=
ts
  that share our design goals and methodologies.

- The N+1 protocol: https://xkcd.com/927/ might just be a part of life. I
  expect we'll be seeing a proliferation of Noise-based VPN protocols,
  tailored for different use cases and environments, with differing securit=
y
  properties and attack surfaces. Designing protocols always involves
  trade-offs, and there are always interesting arguments for different
  trade-offs, and I wouldn't be surprised if we see some more WireGuard-lik=
e
  things come out. Perhaps someday down the line after years of observation=
,
  there will even be improvements made for a new WireGuard protocol,
  incorporating the rejuvenated research that's now being put into these ty=
pes
  of settings. Or not. But maybe. But either way, it seems likely there wil=
l
  be various N+1 protocol proposals and implementations, because people
  apparently like to make things; see XKCD.

So, if WireGuard remains a small niche project, we'll keep on keeping on
quietly and surely as ever. But should things continue to grow in usage as
we're seeing now, expect to see the various temptations proliferate. But
regardless, I certainly intend to keep WireGuard true to our design goals =
=E2=80=93 of
minimalism, of security conservatism =E2=80=93 and I'll be working hard to =
see that
through.

I should also reiterate that our doors remain very open to open source
developers and projects who wish to join the work we're doing.

Regards,
Jason