WireGuard Upstreaming Roadmap (November 2017)

WireGuard Upstreaming Roadmap (November 2017)

[Jason A. Donenfeld]

Hi folks,

This relates to WireGuard [0].

Following a very nice conference with the Linux kernel networking subsystem
community [1,2], I thought it might be a good idea to spell out the roadmap
for the coming months and the trajectory into upstream, based on my
discussions with several developers and maintainers. There are several threads
of this, the biggest of which surrounds the kernel code base, but there are
some other ends of the WireGuard project as a whole that are also relevant.

The current biggest blocker is issues with the crypto API. Before WireGuard
can go upstream, I intend to embark on a multi-pronged effort to overhaul the
crypto API. I very much need to sync up with Herbert regarding my plans for
this, and start spec'ing things out a bit more formally, so I can begin
concrete discussions with him. I intend to base my work both on feedback
from linux-crypto/Herbert and from the cryptographic research community. I
hope to go to RWC2018 [3] and the subsequent HACS workshop for the academic
engagement side, but of course like all the work I do on the kernel, things
will be highly based in engineering, rather than purely academic, practices.

Dave has strongly encouraged me to post patches sooner rather than later.
So I think before the crypto API is ready to go, I'll likely post a [RFG] --
request for grumbles -- patch set to netdev, in order to have some code
review, so as to gauge where we're at. This patch set will use my current
crypto API, not the kernel's crypto API, with it mentioned in the opening that
I intend to switch to the kernel's crypto API when it looks like the one used
here. This way we'll get early feedback so that the later real [PATCH] series
will go more smoothly.

There are a few WireGuard features that some of you have been waiting for. At
the urging of some folks at the conference, I intend to submit a "core"
WireGuard to upstream, and then use future releases to build on top of that,
to make the initial upstreaming process go as easily as possible. Therefore,
there are three big TODO items that may _or_ may not go in after upstreaming:

 - In-band control messages [possibly not]
 - Netlink multicast event notification
 - GRO integration

Of these, it's most likely I'll implement GRO and leave the other two until
after, but this may change. Since WireGuard already does GSO, it would make
sense to implement the other side of things too. There's also a longer more
ambitious roadmap [4], filled with both easy coding-related things and longer
term design things, but that's out of scope for this email, though many of
which will likely be completed before submission time.

There are also six other threads of development that are ongoing, which I
intend to put a bit more focus on too in the near future:

  - The userspace implementation. I'd like to bring this up to deployment
    quality, which naturally fits into the next area.

  - Mobile apps. It's fairly easy to integrate the userspace implementation
    with existing APIs. The current Android app already works well with the
    kernel module, but of course people want this more easily deployed.

  - Mac and Windows support for the userspace implementation. These are
    already mostly done, but the APIs used may in fact change, so there may
    still be a bit of work to do here before we're satisfied.

  - Bindings and libraries. Now that we have a stable Netlink API, we can
    start making nice wrappers for the various languages people like to use.
    It remains to be seen whether or not a C "libwireguard" is needed, since in
    that domain, talking Netlink directly is often a better choice, but I do see
    some potential for a pywireguard and the like. This will also be essential
    when the already mentioned plans for event notification and the possibly
    excluded control messages materialize.

  - More formal verification. While we have the cryptographic protocol
    verified, there are still more places where formalism is quite helpful,
    proving more state machines, and even proving C implementations to be
    correct. Work and research is ongoing in this domain.

  - Integration into network managers and routing daemons (mesh and
    traditional). Work has already begun here on systemd-networkd, and others
    are looking into daemons like babel and bird.

So that's where we're at. I hope to have a RFG submitted in the next several
months, and hopefully we gather some nice momentum and get the work
upstreamed and the project completed soon, for some definition of "complete".

If you'd like to work on WireGuard, or simply have any questions, don't
hesitate to email me.

Regards,
Jason


[0] https://www.wireguard.com/
[1] https://www.netdevconf.org/2.2/
[2] https://www.wireguard.com/presentations/
[3] https://rwc.iacr.org
[4] https://www.wireguard.com/todo/

Re: WireGuard Upstreaming Roadmap (November 2017)

[Stefan Tatschner]

Hi Jason,

thanks for providing all these information. I am looking forward to
the further development of wireguard!

On Sat, Nov 11, 2017 at 5:48 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> The current biggest blocker is issues with the crypto API. Before WireGuard
> can go upstream, I intend to embark on a multi-pronged effort to overhaul the
> crypto API. I very much need to sync up with Herbert regarding my plans for
> this, and start spec'ing things out a bit more formally, so I can begin
> concrete discussions with him. I intend to base my work both on feedback
> from linux-crypto/Herbert and from the cryptographic research community. I
> hope to go to RWC2018 [3] and the subsequent HACS workshop for the academic
> engagement side, but of course like all the work I do on the kernel, things
> will be highly based in engineering, rather than purely academic, practices.

I have a question which is related to the involved crypto. As far as I
have understood the protocol and the concept of wireguard, there is no
crypto agility in the design. That means we cannot easily replace the
underlying cryptographic primitives without breaking things. Please
correct me if I am wrong.

The website states:
> WireGuard uses state-of-the-art cryptography, like the Noise protocol framework,
> Curve25519, ChaCha20, Poly1305, BLAKE2, SipHash24, HKDF, and secure trusted
> constructions. It makes conservative and reasonable choices and has been reviewed
> by cryptographers.

Assuming I am right according the crypto agility, what's the upgrade
path if any of the involved cryptographic algorithms will be declared
insecure/broken? From my point of view wireguard tries to stay as
simple as possible and in general that's a good idea. I am just a bit
worrying about the possible lack of a clear upgrade path once
wireguard is mainlined.

What's your opinion on this?

Thanks!

Stefan

Re: WireGuard Upstreaming Roadmap (November 2017)

[Jason A. Donenfeld]

On Thu, Dec 7, 2017 at 11:22 AM, Stefan Tatschner
<rumpelsepp@sevenbyte.org> wrote:
> I have a question which is related to the involved crypto. As far as I
> have understood the protocol and the concept of wireguard
> What's your opinion on this?

This thread has been picked up on the WireGuard mailing list, not here.

Since this concerns the interworkings of the protocol and cryptography
as a whole, as opposed to implementation details of Linux, please do
not send these inquiries to LKML. Additionally, please start new
threads for new topics in the future, rather than hijacking a roadmap
thread.

Look for my answer on the other mailing list. I'll CC you too.

Regards,
Jason

Re: WireGuard Upstreaming Roadmap (November 2017)

[David Miller]

From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: Fri, 8 Dec 2017 03:17:40 +0100

> On Thu, Dec 7, 2017 at 11:22 AM, Stefan Tatschner
> <rumpelsepp@sevenbyte.org> wrote:
>> I have a question which is related to the involved crypto. As far as I
>> have understood the protocol and the concept of wireguard
>> What's your opinion on this?
> 
> This thread has been picked up on the WireGuard mailing list, not here.
> 
> Since this concerns the interworkings of the protocol and cryptography
> as a whole, as opposed to implementation details of Linux, please do
> not send these inquiries to LKML. Additionally, please start new
> threads for new topics in the future, rather than hijacking a roadmap
> thread.
> 
> Look for my answer on the other mailing list. I'll CC you too.

Sorry, you cannot force the discussion of a feature which will be submitted
upstream to occur on a private mailing list.

It is _ABSOLUTELY_ appropriate to discss this on netdev since it is the
netdev community which must consider issues like this when looking at
whether to accept WireGuard upstream.

Jason, this action and response was entirely inappropriate, and please
I'd like you to reply properly to questions about your feature here.

Thank you.

Re: WireGuard Upstreaming Roadmap (November 2017)

[Jason A. Donenfeld]

Hi Dave,

On Fri, Dec 8, 2017 at 4:38 PM, David Miller <davem@davemloft.net> wrote:
> Sorry, you cannot force the discussion of a feature which will be submitted
> upstream to occur on a private mailing list.
>
> It is _ABSOLUTELY_ appropriate to discss this on netdev since it is the
> netdev community which must consider issues like this when looking at
> whether to accept WireGuard upstream.
>
> Jason, this action and response was entirely inappropriate, and please
> I'd like you to reply properly to questions about your feature here.

Whoops, okay! Very sorry. I'm actually kind of happy to hear that. I
had assumed that you'd be annoyed if WireGuard crypto discussion
spewed over into netdev adding even more message volume there for
something perhaps not directly relevant. But in fact, you're
interested and find it important to discuss there. So, good news. And
sorry for trying to shew it away before. I'll copy and paste the
response I had made on the other list:

> This is covered in the paper:
> https://www.wireguard.com/papers/wireguard.pdf
>
> The basic answer is that WireGuard has message type identifiers, and
> the handshake also hashes into it an identifier of the primitives
> used. If there's ever a problem with those primitives chosen, it will
> be possible to introduce new message type identifiers, if that kind of
> "support everything even the broken garbage" approach is desired by
> misguided people. However, a better approach, of course, is to keep
> your secure network separate from your insecure network, and to not
> allow insecure nodes on secure segments; when you mix the two,
> disaster tends to strike. So, in other words, both approaches to "upgrading"
> are possible, in this fantasy wireguardalypse. Take note, though, that
> neither one of these approaches (support new and retain old protocol
> too for old nodes, or only support new) are "agile" or are anything at
> all like the 90s "cipher agility" -- the user still is not permitted
> to "choose" ciphers.

Regards,
Jason