<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 20, 2018 at 5:20 PM, Ximin Luo <span dir="ltr"><<a href="mailto:ximin@dfinity.org" target="_blank">ximin@dfinity.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">(reposting to the list, I'll learn one of these days..)<br></div><div class="gmail_quote"><span class=""><br>On Fri, Apr 6, 2018 at 7:59 PM, Jason A. Donenfeld <span dir="ltr"><<a href="mailto:Jason@zx2c4.com" target="_blank">Jason@zx2c4.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[..]<br>
<br><span class="">
Let me know if you have any more questions or ways in which I can help<br>
you guys out with the p2p protocol.<br><br></span></blockquote><span class=""><div><br><div>Hey, thanks for the reply. Another issue came up while I've been looking into this:<br><br></div><div>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).<br><br></div><div>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.<br><br>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.<br><br></div><div>Other suggestions would be much appreciated.<br><br></div></div></span></div></div></div></blockquote><div><br></div><div>Here is another option that adds a half-round but is much simpler than either of my suggestions above and doesn't involve modifying WG, so I think I'll go with that. Might be useful for other people looking to do dynamic auth on top of WG.<br><br></div><div>Peer A first authenticates and locates B via the parent protocol, adds B as a WG peer, then:<br></div><div> -> zk-proof "I am A, I am allowed to connect to you B"<br></div><div>Peer B verifies this proof and adds A as a WG peer, triggering the standard WG protocol flow<br></div><div> <- WG initiation, Noise_IKpsk2, etc<br></div><div> -><br></div><div> <-, etc<br></div><div> <br></div><div>Since it authorises the keys and WG stores these, it shouldn't be necessary to re-run this after e.g a disconnection, WG should "just work" by itself.<br><br></div><div>X<br><br></div></div></div></div>