Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Baptiste Jonglez <baptiste@bitsofnetworks.org>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: [WireGuard] Pull-based peer configuration
Date: Tue, 22 Nov 2016 17:31:41 +0100	[thread overview]
Message-ID: <CAHmME9pMMpmS5BNEeAeRNDLF6ZdDOVkbLVTaUTBM3Yk=u1mGAw@mail.gmail.com> (raw)
In-Reply-To: <20161122130805.GG20343@tuxmachine.polynome.dn42>

Hey,

I've thought about the same sort of thing, too. Indeed this would be
different from an IKE daemon, because it would just be a datastructure
provider, rather than a crypto protocol situation.

I envision two uses of a pull model: "please compute this ECDH
multiplication using some daemon-controlled private key" and "do you
recognize this public key? if so, please tell me the allowed-ips for
it." The former would allow easy integration into userspace smartcard
daemons. The latter would allow easy integration into database
systems.

All and all, this isn't that hard to do. All things that have to do
with public key crypto are already strictly ratelimited and running in
a relatively friendly and safe kthread, which can do things like sleep
and yield to userspace processes. It's just a matter of adding the
machinery and exposing the APIs. I can do this.

But it does add _just a tiny little bit_ of extra complexity, which
can quickly snowball into something dreadful. My general plan for
these more enterprise-centric features is to wait until after the
initial codebase is merged into mainline. I'd like to do the best job
we can do on the core principles and components, and once we have a
solid foundation, consider the best ways of building up. (IPsec did
the opposite -- a massive set of committees designed the whole thing,
and oy gevalt...)

What do you think of this approach to that?

Jason

  reply	other threads:[~2016-11-22 16:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-22 13:08 Baptiste Jonglez
2016-11-22 16:31 ` Jason A. Donenfeld [this message]
2017-02-08 23:23   ` mint (ubuntu) kernel Signing john huttley
2017-02-11  9:14     ` Jason A. Donenfeld
2017-02-11 12:18   ` [WireGuard] Pull-based peer configuration jens
2017-02-11 14:49     ` Jason A. Donenfeld
2019-12-26  1:36     ` F. Hölzlwimmer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHmME9pMMpmS5BNEeAeRNDLF6ZdDOVkbLVTaUTBM3Yk=u1mGAw@mail.gmail.com' \
    --to=jason@zx2c4.com \
    --cc=baptiste@bitsofnetworks.org \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).