<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 26, 2015 at 4:32 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> When Alice introduces Bob to Carol, Alice could generate a random symmetric<br>
> key sent to both parties. Bob and Carol would use this key as an additional<br>
> seed for their PRF chains.<br>
<br>
</span>Works for introductions, that's sort of Kerberos, but:<br>
 - How does Alice open sessions with Bob and Charlie in first place?<br>
It can't be introductions all the way down, being able to connect<br>
based on public key seems desirable somewhere?<br></blockquote><div><br></div><div>We will have some bootstrapping mechanism for this. I'm mostly hand-waving it for now because I'm not as worried about optimizing this bootstrapping, so we can use a standard non-0-RTT approach. Once a node is connected, though, introductions to new nodes in the mesh will be common and so need to be 0-RTT.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 - Using DH means Alice can't read Bob and Charlie's traffic, seems<br>
like a nice if not necessary property<br></blockquote><div><br></div><div>Intuitively it seems nice, but I think the intuition comes from thinking about identity-based access control, whereas in a capability-based system there is in fact no benefit.</div><div><br></div><div>But yes, I'll probably use it anyway, as defense in depth.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Mm, also your introduction keys make it harder for Bob to make further<br>introductions to Charlie without contacting Charlie (I think) which<br>was one of your goals..<br></blockquote><div><br></div><div>The goal was only that Bob shouldn't have to wait for a round trip before further introductions, but he does still have to send some messages. For instance, if Alice introduces Bob to Carol, and then Bob immediately turns around and introduces Dave to Carol, then Bob sends two messages to Carol in the process: one to accept Alice's introduction, and another to initiate an introduction to Dave. But Bob chooses the introduction key, so he doesn't have to wait for any reply before contacting Dave.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> Even if it does work, I would probably keep DH on top of this for defense in<br>
> depth, but the addition of the introduction key seems to mean that merely<br>
> compromising a process's private key gets you nothing on its own.<br>
<br>
</span>Dunno about that, if introduction keys are being encrypted to the<br>
process's private key, then compromising the private key gets you the<br>
introduction keys.<br></blockquote><div><br></div><div>The introduction keys would be encrypted as part of the existing session with the introducer, which itself was initiated based on an introduction key from someone else, and so on back to some initial bootstrap.</div><div><br></div><div>So to catch the introduction key in-flight, you would have to have recorded the whole previous conversation between Alice and Bob <i>and</i> have their introduction key, which in turn would require having compromised some other session, etc.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> Indeed. State management is relatively easy in my case because we're talking<br>
> about processes, so state can be kept in RAM. If the state table gets too<br>
> large, kill the process and start a new one.<br>
><br>
> Then again, the introduction key thing might help here too. If the process<br>
> somehow lost its state while keeping its private key, a replay attack would<br>
> not work because it would be using an introduction key that the receiver<br>
> doesn't recognize. (But again, this seems too easy so I must be missing<br>
> something.)<br>
<br>
</span>The introducer could provide a token or introduction key, and the<br>
parties could strike it out upon receiving the 0-RTT message.  So<br>
that's a whitelist approach to 0-RTT antireplay.<br></blockquote><div><br></div><div>Exactly.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In this case the introducer could execute a replay attack on<br>
introduced parties (by providing the same token twice), but maybe<br>
that's OK.<br></blockquote><div><br></div><div>I think it's OK. When Alice introduces Bob to Carol, she is only giving Bob capabilities which she herself already had. Alice could just as easily make the requests to Carol directly. Alice can't use the replay to set up some state with Carol and then trick Bob into using that state because Alice has no way to initialize Bob's PRF chain to the necessary state to hand off the session -- unless Bob actually sends exactly the same messages to Carol, in which case the replay didn't accomplish anything.</div><div><br></div><div>We do have to carefully think about DoS attacks, where Bob and Carol already have a session, and Alice uses a bogus introduction to disrupt that session.</div><div><br></div><div>-Kenton</div></div></div></div>