<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 16, 2021 at 12:10 PM Kent Borg <<a href="mailto:kentborg@borg.org">kentborg@borg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>On 4/16/21 7:08 AM, Henry Baker wrote:<br>
</div>
<blockquote type="cite">Re:
In wifi terms it sounds like a temporary SSID that is communicated
out-of-band.
<pre>This is precisely what I'd like to avoid.
If I have a point2point connection within my house, there should be no 'SSID' -- temporary or not -- broadcast that is 'visible' outside the house.
</pre>
</blockquote>
<p>If you are doing this on wifi, assume <i>something</i> is
receivable outside the house. Whether it is visible as an
arbitrary SID ("orange-couple-sonic", "inside-mustang-iris"…) or
is invisible—until some sniffer software is updated to display a
description of observed point2point connections—seems a fine
point: Radio signals <i>will</i> be observable. <br>
</p>
<p>Which makes me again wonder what problem is being solved. What
are use cases? There will be a lot of traffic analysis risks, do
you really hope to hide that a rendezvous has happened at all?
(That's hard.) What do you expect to be learnable and what not<span class="gmail_default" style="font-size:small">?</span></p></div></blockquote><div><div class="gmail_default" style="font-size:small">I really can't follow these use cases. For me, the only use case of real interest is Bob wants to use the device he has in his hand to connect to whatever device Alice has to hand at the moment and the job of the protocol architect building a presence service to support that use case is to make that happen no matter what network affordances are involved - WiFi, wired, whatever.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If Alice and Bob are within WiFi range, and they know each other, why don't they just talk? The only reason I can see for anything more elaborate is if we want to actually make use of the WiFi proximity for some post pandemic orgy hookup protocol only accessible to folk certified as having had their shots.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Here are the parts (i.e. specs, not code) I can provide today:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Alice and Bob can create pseudo anonymous identifiers not directly connected to any other identity.</div><div class="gmail_default" style="font-size:small">Alice and Bob can both nominate a presence service of their choice.</div><div class="gmail_default" style="font-size:small">Alice can initiate communication with Bob (or vice versa) and only the presence service knows they connected.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I can even route all the traffic over a network so the only observable external event is that Alice and Bob both changed their communication pattern at the same time. And we can even mask that if the participants are willing to endure some lag.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If I wanted more anonymity/traffic analysis protection, I would likely just introduce an additional blinding layer.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">To allow Alice (@alice) to establish anonymous communications with her, she creates a new id (alice_anon) and requests a connection to @bob which is of course end to end encrypted and contains a proof that this is really @alice. So now Bob can contact Alice without the rendezvous service knowing they are doing this.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I have specified (but not coded) a feature of RUD (formerly RDP) that uses a stateless ticket approach to blind StreamIds. This is a similar concept at a different level.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div></div>