[noise] Cap'n Proto case (was: Potential redesign?)

[Kenton Varda]

On Sat, Mar 21, 2015 at 2:08 PM, Trevor Perrin <trevp at trevp.net> wrote:

>  - Once Bob and Carol are introduced, do they remember the session and
> reuse it when introduced by other parties, or when re-introduced?
>

Yes.

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.


>  - Is the session specific to a particular resource, or do all
> Bob<->Carol communications flow through a single session?
>

All.


>  - This is really symmetric?  Either Bob or Carol can send the first
> message?
>

Generally, if Alice is giving Bob a capability that points towards Carol,
the first message at the object layer would be Bob -> Carol.

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.


>  - Once Bob is introduced to Carol, does he immediately have the power
> to introduce others to Carol, or is it OK to require some (how much?)
> communication with Carol first?
>

Bob can immediately introduce others to Carol. This will likely be
important for many use cases we have in mind.

 - Assuming Alice is passing around Bob and Carol's prekeys for
> forward secrecy, would you rather have these be reusable and
> time-based (which requires time sync), or one-time-use (more
> book-keeping and communication).
>

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.

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.


>  - Do the first messages exchanged between Bob and Carol need as much
> forward secrecy as later messages?
>

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.


>  - How long-lived are these sessions?
>

Until one of the two processes dies.


>  - Can Bob and Carol later re-establish sessions on their own?
>

No, because once the session ends, either Bob or Carol is no more.


> If you're imagining these messages are sent simultaneously - not in
> sequence - then I'd view that as just two BoxXE messages setting up
> two separate sessions (one for each direction):
>

Makes sense. I suppose that answers the question about separate PRF chains
for each direction.


> > In other words, the session between Bob and Carol initially uses the
> > ephemeral public keys originally used with Alice, and then switches to
> new
> > ephemeral keys as soon as they are received.
>
> I think that would make it hard to destroy your old ephemerals though,
> if you're expected to use them for introductions.
>

Well, Alice can only introduce nodes she's still connected to, so the
ephemerals couldn't have been destroyed yet.


> For the Handshake** messages I'm assuming yes - there's one PRF chain,
> and the messages are ordered, and chained together.
>

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.


> > I also have a more abstract and opinionated question: In Cap'n Proto's
> case,
>
> the "static" keys are per-process. A process generates a new key when it
> > starts up and that key never leaves its address space. Moreover, we
> > encourage process lifetimes to be limited to a day or less (and in
> Sandstorm
> > we will actually have forced restarts).
>
> Hmm, I don't understand how you're going to bootstrap trust - if
> parties are choosing new static keys every day you obviously can't
> configure any static trust relationships.
>
> Is there going to be some sort of PKI or something?
>

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.)

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 *same* 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. :)

-Kenton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20150321/67d45aab/attachment.html>