<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 21, 2015 at 2:08 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - Once Bob and Carol are introduced, do they remember the session and<br>
reuse it when introduced by other parties, or when re-introduced?<br></blockquote><div><br></div><div>Yes.</div><div><br></div><div>It's worth noting that if Bob and Carol have only been introduced through Alice, then according to our security model there is no need to hide their communications from Alice. (In fact, Alice could perfectly well have arranged to proxy messages between Bob and Carol instead of introducing them.) But if Dave later introduces Bob and Carol, then it's important that any messages between Bob and Carol as a result of Dave's introduction be hidden from Alice, and any messages between Bob and Carol as a result of Alice's introduction be hidden from Dave. Of course, if Bob and Carol's communications can be hidden from everyone, that's great too.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - Is the session specific to a particular resource, or do all<br>
Bob<->Carol communications flow through a single session?<br></blockquote><div><br></div><div>All.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - This is really symmetric?  Either Bob or Carol can send the first message?<br></blockquote><div><br></div><div>Generally, if Alice is giving Bob a capability that points towards Carol, the first message at the object layer would be Bob -> Carol.</div><div><br></div><div>That said, I'd like to avoid making assumptions about the object layer within the transport/session layer. Also, at the transport layer it is useful if Bob and Carol both send messages to each other before receiving any in order to facilitate NAT traversal. That is, it may be that Carol is behind a firewall, in which case Bob won't be able to talk to her until he first receives a message from her.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - Once Bob is introduced to Carol, does he immediately have the power<br>
to introduce others to Carol, or is it OK to require some (how much?)<br>
communication with Carol first?<br></blockquote><div><br></div><div>Bob can immediately introduce others to Carol. This will likely be important for many use cases we have in mind.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - Assuming Alice is passing around Bob and Carol's prekeys for<br>
forward secrecy, would you rather have these be reusable and<br>
time-based (which requires time sync), or one-time-use (more<br>
book-keeping and communication).<br></blockquote><div><br></div><div>I think it would have to be time-based, because one-time-use would mean that Alice could potentially run out of prekeys for introducing some particular peer and have to stop and wait for more, which would be pretty complicated to implement.</div><div><br></div><div>I think time-based doesn't really require time sync since all parties are connected. Carol could periodically sends keep-alive messages to Alice which include new prekeys. Alice always uses the latest pre-key in new introductions, and Carol accepts the previous two pre-keys when receiving introductions.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - Do the first messages exchanged between Bob and Carol need as much<br>
forward secrecy as later messages?<br></blockquote><div><br></div><div>The only meaningful difference between early messages and later messages is that additional introductions may occur, and later introducers need to be defended against earlier introducers (and vice versa) as described earlier.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - How long-lived are these sessions?<br></blockquote><div><br></div><div>Until one of the two processes dies.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - Can Bob and Carol later re-establish sessions on their own?<br></blockquote><div><br></div><div>No, because once the session ends, either Bob or Carol is no more.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you're imagining these messages are sent simultaneously - not in<br>
sequence - then I'd view that as just two BoxXE messages setting up<br>
two separate sessions (one for each direction):<br></blockquote><div><br></div><div>Makes sense. I suppose that answers the question about separate PRF chains for each direction.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> In other words, the session between Bob and Carol initially uses the<br>
> ephemeral public keys originally used with Alice, and then switches to new<br>
> ephemeral keys as soon as they are received.<br>
<br>
I think that would make it hard to destroy your old ephemerals though,<br>
if you're expected to use them for introductions.<br></blockquote><div><br></div><div>Well, Alice can only introduce nodes she's still connected to, so the ephemerals couldn't have been destroyed yet.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For the Handshake** messages I'm assuming yes - there's one PRF chain,<br>
and the messages are ordered, and chained together.<br></blockquote><div><br></div><div>This won't work well for Cap'n Proto since Bob needs to be able to send messages to Carol asynchronously before completing the handshake. But treating the two directions as two independent sessions as mentioned above seems to solve the problem.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> I also have a more abstract and opinionated question: In Cap'n Proto's case,<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> the "static" keys are per-process. A process generates a new key when it<br>
> starts up and that key never leaves its address space. Moreover, we<br>
> encourage process lifetimes to be limited to a day or less (and in Sandstorm<br>
> we will actually have forced restarts).<br>
<br>
Hmm, I don't understand how you're going to bootstrap trust - if<br>
parties are choosing new static keys every day you obviously can't<br>
configure any static trust relationships.<br>
<br>
Is there going to be some sort of PKI or something?<br></blockquote><div><br></div><div>Bootstrapping trust from long-lived keys will happen at a different level. For example, it could be that a DNS-like system returns not only an address but also the current process key, signed by a long-term key. (Incidentally, this means that the live process never needs to see the long-term key which helps reduce the damage from heartbleed-type attacks.)</div><div><br></div><div>Maybe a better question here is: Can you claim to have forward secrecy if you are using the same ephemeral key for multiple different connections within a particular limited timeframe? Like, for the sake of argument, say we're rotating keys every two minutes and updating all clients each time the key changes -- but we send the <i>same</i> new key to all clients. After rotating keys we destroy the old key. It seems to me that this is just as good for forward secrecy as if we used a different ephemeral key for each session -- in fact, it seems better than having one key per session where the sessions are long-lived. But I am not a cryptographer so I am probably missing something. :)</div><div><br></div><div>-Kenton</div></div></div></div>