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ût 2018 à 23:52, Jason A. Donenfeld <Jason at zx2c4.com> a écrit :
>
> 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 project
> and with the protocol. This inevitably leads to the question: what do we
> actually want WireGuard to be, as a project, as a protocol, as a set of
> implementations, as a design methodology, and so forth? I've had a pretty
> clear idea about that, but I don't think I've ever tried to communicate
> aspects of it in this context, so I thought here I'd highlight two important
> design goals that motivate us.
>
> 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 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. Even
> from a cryptography and implementation perspective, the protocol is designed
> 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 fuller
> system.
>
> Secondly, WireGuard is engineered slowly and carefully. It is a conservative
> 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 assurance
> 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 expect
> for this to continue. But indeed not all programmers share this perspective –
> for a wide variety of motivations, both benign and opportunistic – and so we
> definitely will (and have, in fact, already) see folks making things related
> 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, 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 embrace
>   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 tempted
>   to extend minimal things in grotesque ways, and to push them to market with
>   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 directly
>   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 of
>   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 fun
>   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 commercial
>   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 projects
>   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 security
>   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-like
>   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 types
>   of settings. Or not. But maybe. But either way, it seems likely there will
>   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 – of
> minimalism, of security conservatism – 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
> _______________________________________________
> WireGuard mailing list
> WireGuard at lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard