From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ximin@dfinity.org Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 821b6163 for ; Fri, 20 Apr 2018 15:20:26 +0000 (UTC) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 3a2e2580 for ; Fri, 20 Apr 2018 15:20:26 +0000 (UTC) Received: by mail-io0-f180.google.com with SMTP id q84-v6so10947428iod.10 for ; Fri, 20 Apr 2018 08:20:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Ximin Luo Date: Fri, 20 Apr 2018 17:20:39 +0200 Message-ID: Subject: Re: Using WG for transport security in a p2p network To: "Jason A. Donenfeld" Content-Type: multipart/alternative; boundary="000000000000179041056a493b9a" Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --000000000000179041056a493b9a Content-Type: text/plain; charset="UTF-8" (reposting to the list, I'll learn one of these days..) On Fri, Apr 6, 2018 at 7:59 PM, Jason A. Donenfeld wrote: > [..] > > Let me know if you have any more questions or ways in which I can help > you guys out with the p2p protocol. > > Hey, thanks for the reply. Another issue came up while I've been looking into this: At present, one has to manually add specific peers in order for WG to authenticate them. I was wondering what the options are for dynamic authentication, of peer keys that one doesn't know beforehand. The typical example would be a PAKE but for us it would be an alternative zero-knowledge proof that the initiator's key belongs to some allowed-set of peers wrt the responder's key, as defined by the rest of the protocol (I'm being vague because the details are TBD, actually). It would be nice to keep WG's current property of being able to authenticate a client on the first packet without requiring further communication. To reduce the DoS-potential of having to verify a complex zk proof, we can probably also include a proof-of-work linked to a recent global shared source of randomness (we have that in our protocol). So one way would be for WG to hook into a custom function that reads a custom certificate from the first incoming packet and say whether it passes the test. Alternatively we can listen on another socket, perform the custom check on incoming packets here, and then forward passing packets with our custom portion stripped out onto the local WG socket. Hopefully this would "just work" if the "from" address on the UDP packet is correct. However, initiating these would be tricky, we'd have to intercept the WG initial outgoing packet and rewrite it. Other suggestions would be much appreciated. X --000000000000179041056a493b9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(rep= osting to the list, I'll learn one of these days..)

On Fri, Apr 6, 2018 at 7:59 PM, Jason A. Donenfeld <Jas= on@zx2c4.com> wrote:
[..]

Let me know if you have any more questions or ways in which I can help
you guys out with the p2p protocol.


Hey, = thanks for the reply. Another issue came up while I've been looking int= o this:

At present, one has to manually add specific peers in order for WG to=20 authenticate them. I was wondering what the options are for dynamic=20 authentication, of peer keys that one doesn't know beforehand. The=20 typical example would be a PAKE but for us it would be an alternative=20 zero-knowledge proof that the initiator's key belongs to some=20 allowed-set of peers wrt the responder's key, as defined by the rest of= =20 the protocol (I'm being vague because the details are TBD, actually).
It would be nice to keep WG's current property of being able to=20 authenticate a client on the first packet without requiring further=20 communication. To reduce the DoS-potential of having to verify a complex zk proof, we can probably also include a proof-of-work linked to a=20 recent global shared source of randomness (we have that in our=20 protocol). So one way would be for WG to hook into a custom function=20 that reads a custom certificate from the first incoming packet and say=20 whether it passes the test.

Alternatively we can listen on=20 another socket, perform the custom check on incoming packets here, and=20 then forward passing packets with our custom portion stripped out onto=20 the local WG socket. Hopefully this would "just work" if the &quo= t;from"=20 address on the UDP packet is correct. However, initiating these would be tricky, we'd have to intercept the WG initial outgoing packet and=20 rewrite it.

Other suggestions would be much appreciated.<= br>
X

--000000000000179041056a493b9a--