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

[Trevor Perrin]

Thanks for the info, comments inline:


On Sat, Mar 21, 2015 at 3:34 PM, Kenton Varda <kenton at sandstorm.io> wrote:
>>
>> > 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.

In general protocols destroy ephemeral DH private keys immmediately
after a handshake, e.g. Noise envisioned that the parties might do
one-way updating of their cipher keys as they exchange messages, so
that a compromise doesn't reveal old data, but that means you have to
throw the ephemeral DHs away.


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

OK, I'd been assuming the "static" keys *were* the long-lived keys,
but I guess things are different.  You mentioned earlier you would
encourage "process lifetimes to be limited to a day or less".

It's hard to make suggestions about keys/protocols without
understanding all the key management, there's just a lot of ways to
slice these problems, and everything interacts.

But if it's true that processes have "static" keys of a day or less,
you could possibly get by with just Nacl-style boxes (BoxSS), where
you encrypt directly based on static-static DH keys, and live with
forward-secrecy windows of < day (due to static key replacement).
Which gets to your next point:


> 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?

Forward-secrecy, and particularly "perfect" forward secrecy, is sort
of a misnomer.  There's not a binary property here, there's just a
relationship between key lifetimes and how much data is exposed if the
key is compromised.

So the more-quickly you destroy keys for old data the better, but that
has to be balanced against other concerns.


Anyways, one factor I haven't brought up - and that dkg did a good job
bringing up on TLS list recently - is that 0-RTT depends on recipients
maintaining state (whitelists or blacklists) to prevent replays of
initial messages.

I don't know how big an issue that would be in your system.  If you
don't want to deal with that state-management, and the risks it brings
(performance, DoS, losing the state) then accepting a 1-RTT protocol
may be easier.

Trevor