WireGuard Archive on lore.kernel.org
 help / color / Atom feed
* Reflections on WireGuard Design Goals
@ 2018-08-09 21:52 Jason A. Donenfeld
  2018-08-10 15:19 ` nicolas prochazka
  0 siblings, 1 reply; 20+ messages in thread
From: Jason A. Donenfeld @ 2018-08-09 21:52 UTC (permalink / raw)
  To: WireGuard mailing list

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-09 21:52 Reflections on WireGuard Design Goals Jason A. Donenfeld
@ 2018-08-10 15:19 ` nicolas prochazka
  0 siblings, 0 replies; 20+ messages in thread
From: nicolas prochazka @ 2018-08-10 15:19 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: WireGuard mailing list

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-12  0:46         ` Jason A. Donenfeld
@ 2018-08-12  1:07           ` Aaron Jones
  0 siblings, 0 replies; 20+ messages in thread
From: Aaron Jones @ 2018-08-12  1:07 UTC (permalink / raw)
  To: Jason; +Cc: WireGuard mailing list

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-12  0:15       ` Aaron Jones
@ 2018-08-12  0:46         ` Jason A. Donenfeld
  2018-08-12  1:07           ` Aaron Jones
  0 siblings, 1 reply; 20+ messages in thread
From: Jason A. Donenfeld @ 2018-08-12  0:46 UTC (permalink / raw)
  To: A Jones; +Cc: WireGuard mailing list

[-- 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 --]

<div dir="auto"><div><br><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Aug 11, 2018, 17:15 Aaron Jones &lt;<a href="mailto:aaronmdjones@gmail.com">aaronmdjones@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
On 11/08/18 22:52, Luiz Angelo Daros de Luca wrote:<br>
&gt; I see these wireguard extra features just like dhcp is. Nobody<br>
&gt; thinks about implementing dhcp inside kernel or even iproute<br>
&gt; tools.<br>
<br>
The Linux kernel has a (minimal, non-configurable) DHCP client already<br>
(used for rootfs on NFS without an initramfs, among other things).<br>
<br>
CONFIG_IP_PNP_BOOTP=y<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This is in fact true, but I&#39;m not sure we&#39;re planning on following suite with that kind of thing in kernel space for WireGuard...</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-----BEGIN PGP SIGNATURE-----<br>
Comment: Using GnuPG with Thunderbird - <a href="https://www.enigmail.net/" rel="noreferrer noreferrer" target="_blank">https://www.enigmail.net/</a><br>
<br>
iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAltvfB4ACgkQivBzdIir<br>
MBLldA//aCK1DHoew8joweZkI2coLZjolMqPActFDTtDkIXAka3guJjh2zVDCxVF<br>
45AdF1Xv7jhmuDB4emCgH6ANk0vPDAHvs6SBYYZgHvvHdNbBzmM9FqJFk01KHUkl<br>
LhPVCjR9T9EMNifoP5EI1R3YTpoAQbUpaJJ9K12rumdGMelpVU7qg7hW7VkscwAq<br>
WtmN/wuD3w3mZKH+TvtlT409JefvocvE9kA7NUXWOZ9Bxxj3pEJIVTmquE6MS4rm<br>
zHcQ7hY3JR7cPg4Imc0FHuyvbU55R2AnU9+00+dTUISlBT9k2pneIw4EhW0WSHLK<br>
uXXplZfpwV9WSiI/n1dXX1RdRc/42U6LsD4ZLPr6uxoULyeM0ahW7P2+Zq7+yt34<br>
gEDjwTdLSLQYpLEWhAZ4q6fBLGamZHqXgLXTtioWrIqr5eaScYJcINNjsnAEa8Kz<br>
3Oo5HOxvJvEMyDz35M+04ugAbjW5LHiqWsOoWfX0A2XfDPt9mnTuiPXrGSLEPWdh<br>
5OvOsPAmda4/CbJo83cRHqwhsOvoxIJX5+Ewx8giyLZ4lWIGum57wD6n6ZaUVsHZ<br>
9OXA8f7LZdkxKZ/QSFi7HN9S7SRdkCbJB9E0L96AAVhPGbZuXkGavN5sIOA3fd7Y<br>
CWMCI3Y+x675gtYTpVooR+P1fTWgBAHOHuVFeU8e+LSHwhMallc=<br>
=OY67<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
WireGuard mailing list<br>
<a href="mailto:WireGuard@lists.zx2c4.com" target="_blank" rel="noreferrer">WireGuard@lists.zx2c4.com</a><br>
<a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" rel="noreferrer noreferrer" target="_blank">https://lists.zx2c4.com/mailman/listinfo/wireguard</a><br>
</blockquote></div></div></div>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-11 22:52     ` Luiz Angelo Daros de Luca
@ 2018-08-12  0:15       ` Aaron Jones
  2018-08-12  0:46         ` Jason A. Donenfeld
  0 siblings, 1 reply; 20+ messages in thread
From: Aaron Jones @ 2018-08-12  0:15 UTC (permalink / raw)
  To: Luiz Angelo Daros de Luca; +Cc: WireGuard mailing list

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-11 19:18   ` Jason A. Donenfeld
@ 2018-08-11 22:52     ` Luiz Angelo Daros de Luca
  2018-08-12  0:15       ` Aaron Jones
  0 siblings, 1 reply; 20+ messages in thread
From: Luiz Angelo Daros de Luca @ 2018-08-11 22:52 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: WireGuard mailing list, Brian Candler

[-- 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 --]

<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think that given the WireGuard building block, it&#39;s certainly<br>
possible to build a 2FA framework around it. <br></blockquote></div><div><br></div><div>I see these wireguard extra features just like dhcp is. Nobody thinks about implementing dhcp inside kernel or even iproute tools.</div><div><br></div><div>+1 for 2FA and +1 for a service that share peer info, allowing a mesh vpn</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p dir="ltr">Luiz Angelo Daros de Luca<br>
<a href="mailto:luizluca@gmail.com">luizluca@gmail.com</a></p>
</div></div>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-10 13:35 ` Brian Candler
                     ` (5 preceding siblings ...)
  2018-08-10 20:15   ` em12345
@ 2018-08-11 19:18   ` Jason A. Donenfeld
  2018-08-11 22:52     ` Luiz Angelo Daros de Luca
  6 siblings, 1 reply; 20+ messages in thread
From: Jason A. Donenfeld @ 2018-08-11 19:18 UTC (permalink / raw)
  To: Brian Candler; +Cc: WireGuard mailing list

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-10 20:15   ` em12345
@ 2018-08-10 23:07     ` Reuben Martin
  0 siblings, 0 replies; 20+ messages in thread
From: Reuben Martin @ 2018-08-10 23:07 UTC (permalink / raw)
  Cc: WireGuard mailing list

[-- 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 --]

<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 10, 2018, 3:16 PM em12345 &lt;<a href="mailto:em12345@web.de">em12345@web.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
&gt; From my point of view, the only thing which makes me uncomfortable about<br>
&gt; wireguard is the lack of any second authentication factor. Your private<br>
&gt; key is embedded in a plaintext file in your device (e.g. laptop), not<br>
&gt; even protected with a passphrase.<br>
<br>
Most VPN authentications are just authorizing the machine and not the<br>
user sitting in front of that machine.<br>
<br>
&gt; Anyone who gains access to that<br>
&gt; laptop is able to establish wireguard connections.<br>
&gt;<br>
&gt; Of course, it can be argued that the laptop holds other information<br>
&gt; which is more valuable that the wireguard key, therefore you should<br>
&gt; concentrate on properly securing the laptop itself (*). Furthermore,<br>
<br>
No matter how much keys, passwords or tokens have to be entered by the<br>
user sitting in front of that machine, any other user already on that<br>
machine, will gain sooner or later access to the tunnel. This user or<br>
attacker doesn&#39;t even need to see/know wireguard&#39;s private key nor does<br>
the attacker need root access. Think of a second user logged in on that<br>
machine.<br>
<br>
It is definitely a bad idea to assume that the tunnel traffic of one<br>
&quot;client&quot; (in terms of wg&#39;s client key pair) comes from a specific user.<br>
Which also means that even multi factor VPN authentication still require<br>
all services inside the tunnel to ask for user authentication.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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&#39;s namespace.</div><div dir="auto"><br></div><div dir="auto">-Reuben</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-10 13:35 ` Brian Candler
                     ` (4 preceding siblings ...)
  2018-08-10 15:03   ` Roman Mamedov
@ 2018-08-10 20:15   ` em12345
  2018-08-10 23:07     ` Reuben Martin
  2018-08-11 19:18   ` Jason A. Donenfeld
  6 siblings, 1 reply; 20+ messages in thread
From: em12345 @ 2018-08-10 20:15 UTC (permalink / raw)
  To: wireguard

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-10 17:12         ` Aaron Jones
@ 2018-08-10 17:25           ` jungle Boogie
  0 siblings, 0 replies; 20+ messages in thread
From: jungle Boogie @ 2018-08-10 17:25 UTC (permalink / raw)
  To: Aaron Jones; +Cc: WireGuard mailing list

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-10 16:40       ` jungle Boogie
@ 2018-08-10 17:12         ` Aaron Jones
  2018-08-10 17:25           ` jungle Boogie
  0 siblings, 1 reply; 20+ messages in thread
From: Aaron Jones @ 2018-08-10 17:12 UTC (permalink / raw)
  To: jungle Boogie; +Cc: wireguard

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-10 16:03     ` Brian Candler
  2018-08-10 16:38       ` Kalin KOZHUHAROV
@ 2018-08-10 16:40       ` jungle Boogie
  2018-08-10 17:12         ` Aaron Jones
  1 sibling, 1 reply; 20+ messages in thread
From: jungle Boogie @ 2018-08-10 16:40 UTC (permalink / raw)
  To: Brian Candler; +Cc: WireGuard mailing list

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.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-10 16:03     ` Brian Candler
@ 2018-08-10 16:38       ` Kalin KOZHUHAROV
  2018-08-10 16:40       ` jungle Boogie
  1 sibling, 0 replies; 20+ messages in thread
From: Kalin KOZHUHAROV @ 2018-08-10 16:38 UTC (permalink / raw)
  To: Brian Candler; +Cc: WireGuard mailing list

[-- 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 --]

<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Fri, 10 Aug 2018, 19:04 Brian Candler, &lt;<a href="mailto:b.candler@pobox.com">b.candler@pobox.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="m_5431681004389507295moz-cite-prefix">On 10/08/2018 16:03, Roman Mamedov
      wrote:<br>
    </div>
    <blockquote type="cite">
      <blockquote type="cite" style="color:#000000">
        <pre>But I&#39;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.
</pre>
      </blockquote>
      <pre>Couldn&#39;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.</pre>
    </blockquote>
    <p>But by analogy, would you say that SSH keys and PGP keys don&#39;t
      need protection by a passphrase?</p></div></blockquote></div></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Kalin.</div><div dir="auto"></div></div>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-10 15:03   ` Roman Mamedov
@ 2018-08-10 16:03     ` Brian Candler
  2018-08-10 16:38       ` Kalin KOZHUHAROV
  2018-08-10 16:40       ` jungle Boogie
  0 siblings, 2 replies; 20+ messages in thread
From: Brian Candler @ 2018-08-10 16:03 UTC (permalink / raw)
  To: Roman Mamedov; +Cc: wireguard

[-- 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 --]

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 10/08/2018 16:03, Roman Mamedov
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:20180810200346.0e9646ac@natsu">
      <blockquote type="cite" style="color: #000000;">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">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.</pre>
    </blockquote>
    <p>But by analogy, would you say that SSH keys and PGP keys don't
      need protection by a passphrase?</p>
  </body>
</html>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-10 13:35 ` Brian Candler
                     ` (3 preceding siblings ...)
  2018-08-10 14:47   ` Konstantin Ryabitsev
@ 2018-08-10 15:03   ` Roman Mamedov
  2018-08-10 16:03     ` Brian Candler
  2018-08-10 20:15   ` em12345
  2018-08-11 19:18   ` Jason A. Donenfeld
  6 siblings, 1 reply; 20+ messages in thread
From: Roman Mamedov @ 2018-08-10 15:03 UTC (permalink / raw)
  To: Brian Candler; +Cc: wireguard

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-10 13:35 ` Brian Candler
                     ` (2 preceding siblings ...)
  2018-08-10 14:42   ` Eisfunke
@ 2018-08-10 14:47   ` Konstantin Ryabitsev
  2018-08-10 15:03   ` Roman Mamedov
                     ` (2 subsequent siblings)
  6 siblings, 0 replies; 20+ messages in thread
From: Konstantin Ryabitsev @ 2018-08-10 14:47 UTC (permalink / raw)
  To: Brian Candler; +Cc: wireguard

[-- 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 --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-10 13:35 ` Brian Candler
  2018-08-10 14:09   ` Matthias Urlichs
  2018-08-10 14:09   ` Kalin KOZHUHAROV
@ 2018-08-10 14:42   ` Eisfunke
  2018-08-10 14:47   ` Konstantin Ryabitsev
                     ` (3 subsequent siblings)
  6 siblings, 0 replies; 20+ messages in thread
From: Eisfunke @ 2018-08-10 14:42 UTC (permalink / raw)
  To: wireguard; +Cc: Brian Candler

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-10 13:35 ` Brian Candler
  2018-08-10 14:09   ` Matthias Urlichs
@ 2018-08-10 14:09   ` Kalin KOZHUHAROV
  2018-08-10 14:42   ` Eisfunke
                     ` (4 subsequent siblings)
  6 siblings, 0 replies; 20+ messages in thread
From: Kalin KOZHUHAROV @ 2018-08-10 14:09 UTC (permalink / raw)
  To: Brian Candler; +Cc: WireGuard mailing list

[-- 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 --]

<div dir="auto"><div>Please excuse my brevity, phone typing here...<br><br><div class="gmail_quote"><div dir="ltr">On Fri, 10 Aug 2018, 16:36 Brian Candler, &lt;<a href="mailto:b.candler@pobox.com">b.candler@pobox.com</a>&gt; wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for explaining the project background, and your very sensible <br>
goals of simplicity and robustness.  And thanks for releasing this <br>
excellent piece of software.<br>
<br>
 From my point of view, the only thing which makes me uncomfortable <br>
about wireguard is the lack of any second authentication factor. Your <br>
private key is embedded in a plaintext file in your device (e.g. <br>
laptop), not even protected with a passphrase. </blockquote></div></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Anyone who gains access <br>
to that laptop is able to establish wireguard connections.<br>
<br>
Of course, it can be argued that the laptop holds other information <br>
which is more valuable that the wireguard key, therefore you should <br>
concentrate on properly securing the laptop itself (*). Furthermore, to <br>
be able to talk to the wireguard kernel module you&#39;re already root, and <br>
therefore have all sorts of malicious options available to you. etc etc<br>
<br>
But I&#39;d feel a lot happier if a second level of authentication were <br>
required to establish a wireguard connection, if no packets had been <br>
flowing for more than a configurable amount of time - say, an hour. It <br>
would give some comfort around lost/stolen devices.<br></blockquote></div></div><div dir="auto">And what do we do (count or not) keepalive traffic?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Whilst I appreciate that wireguard is symmetrical, a common use case is <br>
to have remote &quot;clients&quot; with a central &quot;office&quot;.  I&#39;m thinking about a <br>
hook whereby the &quot;office&quot; side could request extra authentication when <br>
required - e.g. if it sees a connection from a wireguard public key <br>
which has been idle for more than a configurable amount of time, then it <br>
sends a challenge which requires (e.g.) a Yubikey to complete.  I <br>
appreciate that it&#39;s not going to be straightforward, requiring the <br>
kernel module to talk to userland components at both ends.<br></blockquote></div></div><div dir="auto">That is way overcomplicated... </div><div dir="auto">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?</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In the absence of that, it would be nice if the private key which is <br>
stored on the laptop were encrypted with a passphrase.  Simplest option <br>
may be to extend wg-quick so that the entire config file can be <br>
pgp-encrypted.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div dir="auto">Now that also is not 2FA, and yes it should be a few lines of scripting.</div><div dir="auto"><br></div><div dir="auto">Kalin.</div></div>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
  2018-08-10 13:35 ` Brian Candler
@ 2018-08-10 14:09   ` Matthias Urlichs
  2018-08-10 14:09   ` Kalin KOZHUHAROV
                     ` (5 subsequent siblings)
  6 siblings, 0 replies; 20+ messages in thread
From: Matthias Urlichs @ 2018-08-10 14:09 UTC (permalink / raw)
  To: wireguard

[-- 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 --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: Reflections on WireGuard Design Goals
       [not found] <mailman.1318.1533866648.2201.wireguard@lists.zx2c4.com>
@ 2018-08-10 13:35 ` Brian Candler
  2018-08-10 14:09   ` Matthias Urlichs
                     ` (6 more replies)
  0 siblings, 7 replies; 20+ messages in thread
From: Brian Candler @ 2018-08-10 13:35 UTC (permalink / raw)
  To: wireguard

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, back to index

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-09 21:52 Reflections on WireGuard Design Goals Jason A. Donenfeld
2018-08-10 15:19 ` nicolas prochazka
     [not found] <mailman.1318.1533866648.2201.wireguard@lists.zx2c4.com>
2018-08-10 13:35 ` Brian Candler
2018-08-10 14:09   ` Matthias Urlichs
2018-08-10 14:09   ` Kalin KOZHUHAROV
2018-08-10 14:42   ` Eisfunke
2018-08-10 14:47   ` Konstantin Ryabitsev
2018-08-10 15:03   ` Roman Mamedov
2018-08-10 16:03     ` Brian Candler
2018-08-10 16:38       ` Kalin KOZHUHAROV
2018-08-10 16:40       ` jungle Boogie
2018-08-10 17:12         ` Aaron Jones
2018-08-10 17:25           ` jungle Boogie
2018-08-10 20:15   ` em12345
2018-08-10 23:07     ` Reuben Martin
2018-08-11 19:18   ` Jason A. Donenfeld
2018-08-11 22:52     ` Luiz Angelo Daros de Luca
2018-08-12  0:15       ` Aaron Jones
2018-08-12  0:46         ` Jason A. Donenfeld
2018-08-12  1:07           ` Aaron Jones

WireGuard Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://lore.kernel.org/wireguard \
		wireguard@lists.zx2c4.com zx2c4-wireguard@archiver.kernel.org
	public-inbox-index wireguard


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.zx2c4.lists.wireguard


AGPL code for this site: git clone https://public-inbox.org/ public-inbox