<div dir="ltr"><div class="gmail_default" style="font-size:small">I find this 'anonymous rendezvous' concept to be rather mushy and ill defined. Ditto the concept of 'trusted third party'.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So Alice wants to establish communication with Bob without Mallet knowing that they are talking. What are we going to allow them?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* Prior knowledge of the credentials, IP address of the other?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* Use of the IP address of the other party's device?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* Third party providing a dead drop?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* How many other people are using the same network?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As with many problems of this sort, unless we start with a clearly defined understanding of what the constraints are, we cannot understand the degree to which the communication can be made resistant to traffic analysis.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Note the use of the term 'degree to which'. Tor allegedly provides traffic analysis resistant messaging but as one student kicked out of Harvard learned, no traffic analysis resistant network can help you if you are the only person using that scheme.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The way to firm up the specification is probably to introduce a collection of Bobs and set up the problem as preventing Mallet knowing which particular Bob Alice sent the communication to. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I would specify the Trusted Third Party similarly but I remain skeptical as to the notion that 'zero trust' is possible or even desirable as an absolute. Every party involved in a communication is trusted to at least the degree of providing service. We can limit the degree of trust but trying to eliminate trust completely tends to cause us to end up trusting some other party more. Rather than place 100% trust in one party, I would rather divide that trust across two, three or more parties such that they all need to collude if they are going to successfully attack me.</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 been considering these issues at some length in the design of Reliable User Datagram, which began as a presentation layer for Web services. When Alice is talking to her Mesh Service Provider, I want every request and every response to be authenticated and bound to the credentials of the client and service via their respective devices and credentials.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This is essentially SOAP/WS-Security redux but greatly simplified because I only allow for one mode of authentication of the parties (mutual authentication by means of public key exchange with both sides presenting an ephemeral challenge).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So I ended up with datagrams that are prefixed with the destination stream ID which is followed by an encrypted payload and an authentication tag. [Why MAC when you can encrypt]</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One thing I quickly realized is that there is no need for a return address except during the very initial stages of connection setup.</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">If people specify precisely what they mean by 'anonymous rendezvous', I can probably satisfice their requirements if they are consistent.</div></div>