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

[Kenton Varda]

On Thu, Mar 26, 2015 at 4:32 PM, Trevor Perrin <trevp at trevp.net> wrote:

> > When Alice introduces Bob to Carol, Alice could generate a random
> symmetric
> > key sent to both parties. Bob and Carol would use this key as an
> additional
> > seed for their PRF chains.
>
> Works for introductions, that's sort of Kerberos, but:
>  - How does Alice open sessions with Bob and Charlie in first place?
> It can't be introductions all the way down, being able to connect
> based on public key seems desirable somewhere?
>

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.


>  - Using DH means Alice can't read Bob and Charlie's traffic, seems
> like a nice if not necessary property
>

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.

But yes, I'll probably use it anyway, as defense in depth.

Mm, also your introduction keys make it harder for Bob to make further
> introductions to Charlie without contacting Charlie (I think) which
> was one of your goals..
>

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.

> Even if it does work, I would probably keep DH on top of this for defense
> in
> > depth, but the addition of the introduction key seems to mean that merely
> > compromising a process's private key gets you nothing on its own.
>
> Dunno about that, if introduction keys are being encrypted to the
> process's private key, then compromising the private key gets you the
> introduction keys.
>

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.

So to catch the introduction key in-flight, you would have to have recorded
the whole previous conversation between Alice and Bob *and* have their
introduction key, which in turn would require having compromised some other
session, etc.

> Indeed. State management is relatively easy in my case because we're
> talking
> > about processes, so state can be kept in RAM. If the state table gets too
> > large, kill the process and start a new one.
> >
> > Then again, the introduction key thing might help here too. If the
> process
> > somehow lost its state while keeping its private key, a replay attack
> would
> > not work because it would be using an introduction key that the receiver
> > doesn't recognize. (But again, this seems too easy so I must be missing
> > something.)
>
> The introducer could provide a token or introduction key, and the
> parties could strike it out upon receiving the 0-RTT message.  So
> that's a whitelist approach to 0-RTT antireplay.
>

Exactly.


> In this case the introducer could execute a replay attack on
> introduced parties (by providing the same token twice), but maybe
> that's OK.
>

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.

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.

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